Postanowiłem sprawdzić, ile zajęłoby przystępne wyjaśnienie warunków LGPL przeciętnemu użytkownikowi, szczególnie nastawionemu na działalność komercyjną. Dodałem do roboczej wersji dokumentacji odpowiedni dodatek i zacząłem pisanie. Wynikiem była rozciągająca się na dwa ekrany lista z objaśnieniami, dlaczego i jak twórcy serwisów WWW na zamówienie mogą z niej korzystać, kiedy trzeba udostępnić kod źródłowy i tak dalej. Oczywiście jest to nie do zaakceptowania - sam nie lubię zbytnio zbyt skomplikowanych ograniczeń i nie mam zamiaru zmuszać w ten sposób bez wyraźnego powodu innych.
Powodem, dla którego wybrałem licencję GPL, była paradoksalnie chęć ochrony bibliotek przed zamianą w oprogramowanie własnościowe. Taki los spotkał kiedyś projekt Wine, rozpowszechniany początkowo na licencji MIT. Po pewnym czasie powstały zamknięte, komercyjne wersje dostępne bez kodu źródłowego. Co prawda jedna 150-kilobajtowa biblioteka specjalnej wartości handlowej nie ma, ale wolę spać spokojnie, tym bardziej, że mają pojawić się inne. Niestety nie ma żadnej licencji, która od razu pasowałaby do potrzeb:
- Dawała pełne prawa do łączenia zarówno z kodem open-source, jak i własnościowym pod warunkiem zachowania informacji o autorach, a w przypadku kodu źródłowego zachowania w stosunku do niego warunków licencji.
- Nakazywałaby rozpowszechnianie samej biblioteki (przeznaczonej do łączenia z innymi programami) także w postaci kodu źródłowego, co automatycznie implikowałoby zachowanie licencji.
Myślę, że takie ujęcie oprogramowania open-source najlepiej chroni prawa końcowego użytkownika. Zabraniając samodzielnej redystrybucji jedynie w postaci binarnej i ze zmienioną licencją, ma on pewność, że jeśli znajdzie jakąś paczkę OPT, będzie mógł z niej skorzystać na takich samych warunkach, jak z oryginału. Jeśli zaś trafi na zamkniętą wersję, oznacza to, że może być ona przystosowana, a na pewno jest przeznaczona do pracy z jednym, konkretnym skryptem.
Najpewniejszym kandydatem na licencję jest jakaś zmodyfikowana wersja licencji BSD bez klauzuli ogłoszeniowej. Niestety trzeba się pobawić w dodanie do niej rzeczonego warunku w języku angielskim. Dobór właściwego słownictwa trochę potrwa i zapewne nie obejdzie się bez jakiejś pomocy bądź porady kogoś z zachodu. Dlatego wersje rozwojowe w dalszym ciągu będą dostępne na GNU LGPLv3, natomiast wersję finalną przygotuję już na nowej, znacznie łatwiejszej w użyciu licencji.
Oprócz tego, chciałbym udostępnić także wersje płatne bibliotek, niezależnie od tego, że sam kod rozpowszechniany będzie niezwykle liberalnie. Nie byłyby one drogie - myślę, że cena wahałaby się w granicach 20-40 złotych tak, żeby mógł sobie na nią pozwolić niemal każdy zainteresowany. Dochód byłby przeznaczony głównie na utrzymanie domen, serwerów i cele promocyjne, gdyż utrzymanie tego wszystkiego trochę pieniędzy kosztuje. O ile pod względem kodu wersja taka nie różniłaby się od darmowej, nabywca dostawałby kilka bonusów. Aktualnie mam pomysły na następujące:
- Dodatkowe materiały informacyjne.
- Prawo do włączenia materiałów informacyjnych do dokumentacji końcowej użytkownika.
- Przykładowe projekty wraz z kodem źródłowym i szeregiem komentarzy.
- Wcześniejszy dostęp do nowych wersji (np. tydzień)
- Dodatkowe wydania pojawiające się np. w przypadku znalezienia jakiegoś nie-krytycznego błędu, zawierające stosowną poprawkę.
- Możliwość umieszczenia szerszych informacji o projekcie wykorzystującym biblioteki na stronie grupy.
Co o czymś takim sądzicie? Myślę, że na czymś takim zyskają wszyscy: my, bo nie będziemy musieli opłacać serwerów z własnej kieszeni; nabywcy, bo dostaną dodatkowe materiały i bonusy, a w dalszej konsekwencji wszyscy użytkownicy, jako że w celu ich przyciągnięcia powstawać będzie więcej tutoriali, artykułów itd.
Hmm, mam mieszane uczucia co do udostępniania płatnej wersji bibliotek. Chciałbym podsunąć całkowicie inny pomysł - rozwijania projektu całą społecznością. Trac z ticketami, repozytorium SVN, itd. Myślę, że OPT to tak dobry projekt, że na pewno znajdą się osoby, które pomogą w tym; trzeba tylko dać możliwość.
Co do wydatków na serwery, itp. - nie wiem, ile by dała podstrona "Donate". Wg mnie, jeśli ktoś na gwałt potrzebuje jakiejś zmiany, poprawki, to wesprze projekt, a w tytule przelewu dopisze "z prośbą o dodanie opcji X".
Jedno drugiego nie wyklucza, tym bardziej że co do grupy mam dalsze plany. Zauważ, że PHP także jest rozwijany w ten sposób: każdy może się przyłączyć, a oprócz tego Zend sprzedaje sobie pakiet Zend Core. Bugtracker mamy, SVN będzie, przygotowania nad wiki rozpoczęte.
Jeśli chodzi o kod, jedyna różnica między "opłaconą", a darmową wersją będzie taka, że jeśli ukaże się jakaś łatka, normalnie będzie ona dostępna przez SVN, a nabywcy otrzymają gotową paczkę do ściągnięcia. A i to też nie zawsze, bo dla każdej głupoty nie będę przygotowywać paczki, zaś krytyczne błędy będą skutkować zupełnie nowym wydaniem, tak jak to miało miejsce w zeszłym roku z OPT 1.1.1 i zbyt wysokim zużyciem pamięci.
Brzmi całkiem dobrze. Jednak jeśli będziecie pobierać jakieś opłaty (np. te 20-40 zł), to osoby contributujące nie będą już tak chętne do pomocy. "Co będę pomagał tworzyć projekt, skoro oni mają z tego kasę?" Musicie dobrać złoty środek - jakiś kompromis między jednym, jak i drugim rozwiązaniem.
Trzeba wyjaśnić jedną rzecz: płacić tak naprawdę użytkownik będzie za te wszystkie tutoriale i dodatkowe prawa. Więc może lepiej będzie nazwać to inaczej: nie "płatna" wersja biblioteki, a płatne materiały i usługi dodatkowe. Oczywiście nie wszystkie tutoriale będą płatne, bo nauczony doświadczeniem z OPT 1.x wiem, jak to jest istotne.
Ponadto teraz nikt na tym nie zarabia, a jakoś nie widzę tłumów z poprawkami pod mymi drzwiami :). Nawet artykułu nikomu się napisać nie chce :). A jak będą pieniądze, można się pokusić o zorganizowanie konkursu programistycznego z niezłymi nagrodami. Inna sprawa: jeśli ktoś tak myśli, to hmmm... według mnie na programistę się nie nadaje ani trochę i z kimś takim na pewno nie chciałbym nigdy i nigdzie pracować. Paskudna krótkowzroczność - popatrz: komuś biblioteki się spodobają i poświęci swój czas na poznanie ich tajników. Zacznie nadsyłać poprawki, modyfikacje itd. Możliwe, że się nam one spodobają i gościa przyjmiemy do grupy. Jeśli nie, nikt mu nie broni opracować własnych materiałów i też ich sprzedawać. Dopóki udostępnia kod źródłowy, jest w porządku.
Proponuję wprowadzić opłaty za integrację biblioteki z popularnymi frameworkami, przykładowo: Zend Framework.
To miał być żart czy rzeczywista propozycja? Jeśli żart, to wyjątkowo kiepski, a jeśli faktyczna propozycja, odpowiedź jest prosta: a z jakiej paki mamy ŻĄDAĆ opłat za coś, co z założenia jest darmowe? Już ja widzę, ile osób by wtedy tego używało.
Z całym szacunkiem, pomysł moim zdaniem jest lepszy niż ten dotyczący rozpowszechniania przykładowych projektów z komentarzami. Sama integracja biblioteki o której wspomniałem nie jest trudna, nie warto WYCHODZIĆ Z PROPOZYCJĄ wprowadzenia płatności za takowego featuresa. Ale już wprowadzenie pluginów, które pozwalają na pełną integrację ze standardowymi helperami widoku wybranych frameworków jet niezwykle kusząca. Skieruj swoją ofertę do klientów/użytkowników młodych i nowoczesnych, rozwijających własne rozwiązania w oparciu o gotowe projekty - i daj im możliwość podjęcia szybkiej decyzji o wykorzystaniu twoich produktów. Nie próbuj zabierać społeczności rzeczy, które są dla niej oczywiste, np. szybkie poprawki. Pozdrawiam.
Tuner: po wyjściu jakichś stabliniejszych wersji OPT2 (co ma nastąpić wkrótce) zamierzam napisać "most" pomiędzy Zend Frameworkiem a OPT wykorzystujący Zend_Layout, ViewRenderer i ze wsparciem helperów, a następnie go opublikować (choćby tu na blogu). Uważasz że to źle, iż udostępnię go za darmo?
"Skieruj swoją ofertę do klientów/użytkowników młodych i nowoczesnych, rozwijających własne rozwiązania w oparciu o gotowe projekty - i daj im możliwość podjęcia szybkiej decyzji o wykorzystaniu twoich produktów"
Wprowadzanie opłaty za taki most to właśnie zaprzeczenie tego co napisałeś powyżej. Jest to gotowy projekt/rozwiązanie i darmowość umożliwia szybkie podjęcie decyzji co do jego użycia.
"Nie próbuj zabierać społeczności rzeczy, które są dla niej oczywiste, np. szybkie poprawki." Uważasz, że Zyx, udostępniając produkt za darmo, nie będzie go wspierał? Jakoś dotychczas nie miał z tym problemów. :P
Wyjaśnij do czego pijesz, bo na tę chwilę wygląda jakbyś przeczył sam sobie. ;)
Uważam, że rozbudowane mosty do frameworków są już daleko idącą ofertą i warto o nich pomyśleć jako o produkcie w dwóch wariantach - tym podstawowym oraz rozszerzonym o pełną integrację.
Nie uważam też, że Zyx może zawieść społeczność :) Śledzę jego poczynania od wydania wydania parsera szablonów "wzorowanym" na PhpBB2, więc jego poczynania już też go trochę poznałem - oczywiście o wiele gorzej niż ty (z wiadomych powodów) ;)
Bardzo chętnie wytłumaczę do czego piję. Bardzo chciałbym pomóc i zastanawiałem się nad propozycjami podanymi przed Zyxa. Zauważyłem, że niektóre z nich były wciskane na siłę, odbierając trochę wolności z wolnego projektu (patrz: szybkość wydawania poprawek zależna od wykupionej wersji), co może odrzucić potencjalnych nabywców; nie ukrywajmy, coś takiego trochę zniesmacza osoby widzące "znaczek" open-source. Uważam, że należy zadać sobie pytanie: kto chciałby zapłacić za specjalną wersję OPT. Na kogo chcecie postawić?
Bardzo chętnie przyjrzę się temu mostkowi do Zend Framework z którego namiętnie korzystam. I nie, nie uważam by udostępnianie go za darmo było złe. Chodzi o to, że nie można dawać wszystkiego za darmo. Za coś nabywca musi zapłacić, a nie zapłaci za coś co nie będzie mu potrzebne (patrz różne potrzeby różnych odbiorców).
Amator zapłaci za dostęp do nowych wersji i bardziej rozbudowaną dokumentację? Z czego i po co? Poszuka innego projektu, który umożliwi mu to mniejszym kosztem - on nie widzi różnicy. "Frameworki - a co to"?
Profesjonaliście trzeba udowodnić, że ta konkretna biblioteka jest dla niego w jakiś sposób zbawieniem. Chce systemu szablonów dla swojego frameworka? Dostanie pełną integrację.
Mam nadzieję, że teraz wyraziłem się jasno :) W cudzysłowie "biznes plan" Panowie! Bez kompromisów, z pójściem na całość :)
Oto moje uwagi:
1. Częstsze wersje za darmo -> będą rzadziej. Przygotowanie takiej paczki trochę czasu zabiera i powyżej pewnej częstotliwości bez jakiejś dodatkowej motywacji uzasadniającej takie posunięcie na pewno nie zejdę (tym bardziej że mam wcale niełatwe studia). Ponadto weź pod uwagę, że te poprawki i tak byłyby na SVN-ie. Różnica polegałaby na tym, że jeśli zapłaciłeś, otrzymasz ładną paczkę, w dodatku już udokumentowaną i przynajmniej przepuszczoną przez procedury testowe i nie będziesz musiał wszystkiego robić sam.
2. Integracja z frameworkami -> jest tutaj jeden zasadniczy problem. Każdy, kto z tego będzie korzystać, jest programistą. OPT jest darmowy, ZF jest darmowy. Dodajemy do tego trochę oleju w głowie i otrzymujemy darmowy port, za który nie trzeba płacić. Jako że większość programistów używa gotowych rozwiązań, takie coś powstałoby bardzo szybko.
3. Dodatkowe artykuły, pomoc techniczna -> tutaj z kolei, by coś takiego stworzyć, trzeba mieć na wstępie trochę talentu pisarskiego, co wśród programistów nie jest regułą. Ponadto mówimy tu o naprawdę nieelementarnych zagadnieniach, których opracowanie wymaga niemalże znajomości kodu źródłowego na pamięć. I również bez dodatkowej motywacji tak dokładnych opracowań tworzyć nie będę.
Zawsze można też dokonywać odpowiednich indywidualnych modyfikacji samego OPT na żądanie za stosowną opłatą.
Jednak ogólnie teraz widzę, że jest to jeszcze pieśń przyszłości, ponieważ obsługa czegoś takiego wymaga sama w sobie istnienia jakiegoś rejestru, infrastruktury sieciowej itd.
A generalnie to myślę, że od jednorazowej opłaty 20 złotych naprawdę żaden polski programista nie zacznie głodować :). Typowo komercyjne produkty też są w planach, lecz jako samodzielne aplikacje, a nie biblioteki lub dodatki do nich. Tylko że aby je stworzyć, potrzebujemy samych bibliotek.
Tak czy siak życzę powodzenia i będę obserwował rozwój grupy. Przy okazji zyxist.com, strona Invenzzia będzie często przeze mnie odwiedzania. Pozdrawiam! :)