Open source w panelu firmowym. Licencja nic nie kosztuje, utrzymanie już tak
Autor:
Paweł Matusiak
·
Większość paneli B2B i CRM stoi na bibliotekach open source, których nikt w firmie nie napisał. Licencja przy pobraniu często nic nie kosztuje. Koszt wychodzi później: przy aktualizacji, przy porzuconej paczce, przy licencji copyleft w kodzie oddawanym klientowi. Sensowna teza jest wąska — open source jako budulec warstw towarowych, z listą zależności i właścicielem w firmie.
W panelu B2B, w CRM i w ewidencji zleceń siedzi kod, którego nikt w firmie nie napisał od zera. Framework, baza, biblioteka do PDF, klient HTTP. To jest open source. Licencja przy pobraniu często nic nie kosztuje.
Po instalacji zostaje inne pytanie. Kto w firmie wie, które paczki weszły do panelu, na jakiej licencji i kto je zaktualizuje, gdy autor przestanie odpowiadać na zgłoszenia.
Open source w oprogramowaniu dla firm ma sens jako materiał na warstwy, których nie warto pisać samemu. Traci go, gdy paczkę traktuje się jak skończony zakup: wpięto, działa, temat zamknięty. Wtedy darmowy kod wychodzi drogo przy nowym rabacie, przy aktualizacji, przy umowie z klientem albo przy poprawce bezpieczeństwa.
Co firma naprawdę ma w panelu, gdy mówi „open source”
W rozmowie z zarządem open source bywa synonimem „za darmo”. W kodzie oznacza coś węższego. Program ma jawną licencję, źródło da się przeczytać, a zwykle także skopiować i zmienić na warunkach tej licencji. Nie znaczy to, że ktoś będzie go utrzymywał bez końca. Nie znaczy też, że wolno go włożyć w każdy produkt i oddać każdemu klientowi.
Typowy panel zamówień nie jest wyspą. Pod spodem siedzi język, framework, serwer, baza i zestaw bibliotek do logowania, poczty, eksportu i integracji. Część z tego jest warstwą towarową: robi to samo w wielu firmach i nie stanowi przewagi. Tam otwarty kod jest racjonalnym punktem wyjścia. Przewaga siedzi wyżej — w cenniku indywidualnym, w obiegu reklamacji, w tym, jak sprzedawca potwierdza stan.
Zależność od cudzego kodu nie zaczyna się w dniu, w którym ktoś ogłasza „strategię open source”. Zaczyna się przy pierwszej instalacji. Ktoś stawia projekt, doinstalowuje paczki, kopiuje fragment z dokumentacji. Po dwóch latach nikt nie pamięta, które biblioteki weszły „na chwilę”. Lista zależności istnieje w pliku blokad wersji. Często nie istnieje w głowie osoby, która odpowiada za panel.
Dlatego spór „otwarty kod albo oprogramowanie zamknięte” jest dla większości małych i średnich firm źle ustawiony. Pytanie, które da się obsłużyć, brzmi inaczej: które warstwy kupujemy jako towar, które piszemy sami, a które bierzemy z rejestru paczek — i kto w firmie ma nad tym pieczę.
Gdy handlowiec otwiera kartę kontrahenta, nie myśli o licencji biblioteki. Myśli, czy cena na ekranie jest tą z aneksu. Jeżeli panel kłamie albo wisi, problem jest biznesowy. Źródło bywa techniczne: paczka do reguł cenowych, której nikt nie ruszał od dwóch wydań frameworka. Framework, na którym stoi panel, sam zwykle jest otwarty. Osobna rozmowa o tym, kiedy taki stos ma sens w aplikacji biznesowej, dotyczy wyboru narzędzia. Ten tekst dotyczy czegoś wcześniejszego: czy firma w ogóle wie, co do stosu dołożono.
Przykład: hurtownia armatury i panel, którego nikt nie inwentaryzuje
Wyobraźmy sobie regionalną hurtownię armatury przemysłowej. Kilkanaście osób w sprzedaży, magazyn przy hali, stałe umowy z instalatorami i kilka cenników zależnych od wolumenu. To przykład, nie klient GESOFT. Typowa sytuacja, w której panel B2B urósł szybciej niż dokumentacja tego, co w nim siedzi.
Panel powstał, gdy Excel z indywidualnymi rabatami przestał się spinać. Sprzedawca w terenie potrzebował tej samej ceny, którą biuro widzi na fakturze. Zamówienie miało iść z telefonu. Stan — z magazynu, nie z pamięci.
Do panelu weszły kolejne paczki. Generator PDF do ofert. Biblioteka do płatności przy zamówieniach przedpłaconych. Moduł wykresów do raportu dla właściciela. Część dołożył stały programista, część — firma, która robiła „szybki ekran na kwartał”. Po tych zleceniach nikt nie spisał, co zostało w projekcie.
Zator wychodzi przy nowej regule rabatu. Właściciel chce próg od wartości koszyka w wybranym asortymencie, a nie od całego zamówienia. Programista mówi, że najpierw trzeba podnieść wersję frameworka, bo obecna nie dostaje już poprawek. Podniesienie psuje generator PDF i pomocnika płatności. Ten drugi nie ma wydania od dawna. Raport dla właściciela stoi na bibliotece, której licencja przy oddawaniu kodu wygląda inaczej niż reszta stosu.
W tej historii nie pomaga „przesiadka na coś zamkniętego” w tydzień. Pomaga rejestr zależności z właścicielem, licencją i datą ostatniej aktualizacji. Oraz decyzja, które paczki zostają, które się zastępuje, a których nie powinno być w panelu sprzedawanym dalej. Porzucony pakiet do płatności nie zniknie sam. Albo firma przejmuje jego utrzymanie, albo wymienia go, zanim kolejna poprawka frameworka znów zatrzyma oferty.
Wspólna lista, którą da się otworzyć bez grzebania w repozytorium, oszczędza spór między magazynem, sprzedażą i osobą, która jedyna umie podnieść wersje paczek. Sprzedawca nadal liczy rabat w arkuszu obok panelu. Magazyn wydaje według innego stanu niż biuro na fakturze. Ideologia otwartego kodu nikogo tego dnia nie interesuje. Interesuje oferta, stan i faktura.
Licencja nie jest formalnością przy sprzedaży i wdrożeniu u klienta
Licencja open source nie jest ozdobnikiem w stopce. Mówi, co wolno zrobić z kodem: używać wewnątrz firmy, zmieniać, łączyć z własnym programem, oddawać klientowi, publikować zmiany. Licencja permisywna — typowe przykłady to MIT i Apache — zostawia firmie dużo swobody, w tym budowę zamkniętego panelu na bazie biblioteki. Licencja copyleft — GPL, często też AGPL — wymaga, przy określonych formach rozpowszechniania, oddania odbiorcy tych samych wolności do kodu.
Tu zaczyna się praktyka, nie teoria. Panel działający tylko na serwerze firmy to inna sytuacja niż panel instalowany u klienta albo udostępniany tak, że kod da się pobrać. AGPL bywa czytany surowiej przy oprogramowaniu sieciowym. To nie zastępuje porady prawnej w konkretnej sprawie. Zastępuje milczenie: jeżeli nikt nie otworzył pliku LICENSE, firma nie wie, na czym stoi.
W hurtowni z przykładu wykres do raportu dołożył podwykonawca, bo szybko wyglądało. Jeżeli ta biblioteka jest copyleft, a firma planuje odsprzedać panel innemu oddziałowi albo partnerowi, pytanie o licencję wraca przy umowie, nie przy wgraniu kodu. Wtedy poprawka trwa dłużej niż sam wykres.
Część bibliotek ma podwójny model: copyleft albo płatna licencja komercyjna. Podwykonawca bierze to, co widać w publicznym repozytorium. Firma może używać paczki na warunkach, których nie zaakceptowałaby przy zakupie. Słowo „darmowe” w opisie nie jest decyzją zakupową. Bywają też licencje źródłowe z zakazem użycia komercyjnego i dodatki darmowe tylko do określonej skali.
Dobra praktyka jest nudna. Przy każdej nowej paczce ktoś sprawdza licencję, zapisuje ją obok nazwy i wersji i wie, czy paczka zostaje wewnątrz systemu, czy może wyciec w dystrybucji. Firma robi to samo, gdy sprawdza, czy wolno użyć zdjęcia produktu w ofercie.
- nazwa paczki i dokładnie ta wersja, która stoi na produkcji
- licencja i czy dotyczy kodu oddawanego klientowi, czy tylko serwera firmy
- osoba albo rola, która odpowiada za aktualizację
- data ostatniego podniesienia wersji i powód, jeśli paczki nie ruszamy
Łańcuch dostaw kodu: lockfile, aktualizacja, zaufanie do rejestru
Kod z rejestru paczek przychodzi z internetu. Firma ufa nazwie, podpisowi wydawcy, serwerowi rejestru i temu, że nikt nie podmienił pliku po drodze. Łańcuch dostaw oprogramowania to ta droga: od autora, przez rejestr, program do paczek, plik blokad, serwer firmy, aż do ekranu sprzedawcy.
Lockfile — composer.lock, package-lock.json i ich odpowiedniki — zapisuje, która dokładnie wersja weszła do panelu. Bez niego „ta sama instalacja” za pół roku może pobrać coś innego. Z nim da się odtworzyć środowisko i powiedzieć nowemu programiście albo osobie z audytu, co naprawdę działa na produkcji.
Aktualizacja jest decyzją, nie odruchem. Wstrzymanie jej zostawia znane luki. Ślepe podnoszenie wersji w piątek psuje panel przed szczytem zamówień. Sensowny rytm jest prosty do opisania i trudny do utrzymania, gdy nikt nie jest właścicielem listy.
- Ktoś czyta ogłoszenie o luce albo changelog i sprawdza, czy nazwa paczki jest w lockfile na produkcji.
- Aktualizacja idzie najpierw na kopię panelu. Tam testuje się logowanie, ofertę, PDF i płatność przedpłaconą.
- Wdrożenie na produkcję wypada poza szczytem zamówień, nie w piątek po południu przed inwentaryzacją.
- W rejestrze zostaje zapis: co podniesiono, kiedy i kto to zatwierdził.
Dla warstw, od których zależy logowanie i płatność, ten rytm jest częścią bezpieczeństwa aplikacji, a nie „sprzątania w kodzie”. Porzucony pakiet jest gorszy niż stary. Stary jeszcze ktoś łata. Porzucony zostawia firmę z wyborem: zostać na martwej wersji, przejąć utrzymanie albo przepisać kawałek panelu.
W przykładzie hurtowni pomocnik płatności nie ma wydania od dawna. Spór o ideę otwartego kodu tu nic nie daje. Brakuje właściciela po stronie firmy i planu B. Gdy jedyna osoba, która umie podnieść wersje paczek, skończyła zlecenie kilka miesięcy wcześniej, ogłoszenie o luce czeka w skrzynce, a panel stoi na starej wersji.
Atak na łańcuch dostaw nie wymaga, by firma była celem z nazwiska. Wystarczy paczka o podobnej nazwie, przejęte konto opiekuna albo złośliwy skrypt w zależności zależności. Instalator pobiera z publicznego rejestru. Jeśli nikt nie pilnuje nazwy i nie pinuje wersji, w panel wchodzi coś, czego nikt nie zamawiał. Audyt bezpieczeństwa aplikacji PHP w takiej sytuacji zaczyna się od listy tego, co w ogóle jest w projekcie, a nie od haseł na slajdzie.
Gdy aktualizacja padnie na produkcji, sprzedawca dzwoni, że panel nie wstaje. Lepszy sygnał przychodzi wcześniej: monitoring odpowiedzi logowania i zapisu zamówienia, zanim pierwsza oferta wróci z błędem. Lockfile nadal jest potrzebny. Monitoring daje czas, żeby wrócić do poprzedniej wersji, zanim magazyn zacznie wydawać „na gębę”.
Społeczność nie jest działem wsparcia z umową
Społeczność wokół biblioteki to zwykle kilka osób, często po godzinach, plus użytkownicy, którzy zgłaszają błędy. Dopóki projekt żyje, firma dostaje poprawki taniej niż przy pisaniu wszystkiego sama. Gdy opiekun znika, zależność od społeczności staje się ryzykiem operacyjnym. Nikt nie ma obowiązku odebrać telefonu w sobotę.
Przy wyborze paczki liczy się więc nie tylko to, czy działa na demonstracji. Liczy się, czy są regularne wydania, czy ktoś odpowiada na zgłoszenia, czy projekt ma więcej niż jednego opiekuna i czy da się go zastąpić inną biblioteką. Właściciel zależności wewnątrz firmy — osoba albo rola, nie „dział IT w ogóle” — jest potrzebny nawet przy dobrze utrzymywanej bibliotece. Ktoś musi powiedzieć: tę paczkę aktualizujemy w tym kwartale, tamtej nie ruszamy, bo jest na wyjściu.
Utrzymanie otwartego kodu w panelu to praca. Czytanie changelogów, test po aktualizacji, czasem łatka, której autor jeszcze nie przyjął. Koszt tej pracy jest realny. Nadal bywa niższy niż koszt napisania i utrzymania własnego generatora PDF albo klienta HTTP. Porównanie ma sens tylko wtedy, gdy obie strony rachunku są widoczne. „Darmowe” bez godzin programisty jest niepełnym rachunkiem.
Widelec, czyli własna kopia porzuconej biblioteki, brzmi jak kontrola. Dla małego generatora dokumentów bywa weekendem. Dla pomocnika płatności staje się drugim produktem, którego firma nie chciała sprzedawać. Mały zespół rzadko utrzyma taki widelec dłużej niż do następnej zmiany w bramce płatniczej. Plan B powinien zakładać wymianę, nie heroiczne utrzymanie cudzego kodu.
Część firm kupuje wsparcie komercyjne do wybranej warstwy open source: systemu operacyjnego, bazy, czasem frameworka. Nie ma w tym sprzeczności. Firma przyznaje, że na tej warstwie potrzebny jest ktoś, kto odbierze zgłoszenie. Na bibliotece do wykresów zwykle nie. Na bazie, w której siedzą zamówienia — często tak. Hurtownia z przykładu może mieć umowę na bazę i jednocześnie bałagan w paczkach JavaScript. Umowa na bazę nie sprząta rejestru.
Gdzie darmowy kod gryzie marżę: rabat, stan, faktura
Sprzedawca hurtowni nie traci dnia na filozofię licencji. Traci go, gdy panel nie liczy progu rabatu, a klient przy bramie czeka na ofertę. Wtedy wraca Excel obok systemu. Cena z arkusza i cena z panelu rozjeżdżają się w ciągu tygodnia. Magazyn wydaje towar według jednego stanu, biuro fakturuje według drugiego.
Całkowity koszt posiadania darmowej biblioteki to nie zero. To czas osoby, która umie ją zaktualizować, ryzyko przestoju, koszt zastąpienia porzuconej paczki, czasem koszt porady przy copyleft. Oszczędność jest gdzie indziej: firma nie płaci za wymyślanie od zera rzeczy, które nie odróżniają jej od konkurencji.
Marża ginie po cichu. Nie w fakturze za licencję, tylko w godzinach ręcznego przeliczenia i w korekcie, która wychodzi po dostawie. Gdy jedyna osoba, która umie podnieść wersje paczek, jest na urlopie, aktualizacja bezpieczeństwa czeka. To też jest koszt. Nie ma na niego osobnej pozycji w księgowości.
Jest jeszcze koszt, który widać u klienta, nie w repozytorium. Właściciel chciał ładny wykres w raporcie. Paczka wciągnęła ciężką bibliotekę do przeglądarki. Sprzedawca na hali u instalatora, na słabym łączu, czeka aż oferta się narysuje. Funkcja, której w terenie nikt nie potrzebuje, spowalnia tę, której potrzebuje każdy: cenę i stan. Zależność od raportu właściciela uszczupla dzień handlowca.
Własny panel nadal może być właściwą drogą, gdy cenniki są indywidualne, a gotowy program nie ogarnia progów, rezerwacji stanu i faktury z tego samego zamówienia. O tym, kiedy gotowy program przestaje się spinać, decyduje proces, nie moda na otwarty kod. Open source jest wtedy budulcem panelu. Nie zastępuje decyzji, czy panel w ogóle jest potrzebny.
Zamknięty stos i kod pisany od zera. Kontrargument
Mocny kontrargument brzmi tak: lepiej kupić zamknięty stos z umową albo napisać kluczowe elementy od zera. Wtedy jest adres, faktura i ktoś, do kogo można się zgłosić, gdy system padnie. Kod własny i oprogramowanie zamknięte dają poczucie kontroli. Dla niektórych warstw to poczucie jest uzasadnione.
Firma ma prawo chcieć umowy z czasem reakcji, kopii zapasowej zapisanej w kontrakcie i człowieka, który przyjmie zgłoszenie w sobotę. Tego otwarty kod sam z siebie nie daje. Daje źródło i licencję. Resztę trzeba zorganizować: hosting, podgląd działania panelu, osobę na dyżurze, procedurę odtworzenia. Brak tej reszty nie jest wadą licencji MIT. Jest luką w organizacji.
Kontrola w stylu „napiszemy wszystko sami” jest jednak złudna w typowym panelu B2B. Framework, system operacyjny, baza, biblioteki szyfrowania, sterowniki — i tak będą cudze, zwykle otwarte. Firma, która „nie chce open source”, i tak go ma, tylko bez listy. Przepisanie frameworka nie jest strategią dla kilkunastoosobowej hurtowni. Zakup komercyjnego silnika raportów albo map może nią być, jeśli ta warstwa jest krytyczna i dostawca naprawdę utrzymuje produkt.
Duży odbiorca bywa surowszy niż własny programista. W kwestionariuszu bezpieczeństwa pyta o spis komponentów, o sposób aktualizacji, o to, kto odpowiada za luki. Bez rejestru dyrektor sprzedaży wpisuje ogólnik albo „nie dotyczy”. Rozmowa o kontrakcie wtedy stoi, choć rabat i stan w panelu działają. Zamknięty dostawca czasem dostarcza taki spis w pakiecie. Przy otwartym stosie spis trzeba zrobić samemu. To argument za dyscypliną, nie automatycznie za zmianą całego panelu.
Ograniczenie proponowanego tu podejścia jest jasne. Rejestr zależności, lockfile i rytm aktualizacji nie zastąpią umowy z hostingiem. Nie zastąpią kopii zapasowej. Nie sprawią, że porzucona biblioteka nagle ożyje. Nie sprawią też, że mały zespół utrzyma widelec dużej paczki. Podejście działa, gdy firma zgadza się utrzymywać niewiele zależności i wymieniać te, których nie ogarnie. Nie działa, gdy panel jest zlepkiem ekranów z tutoriali, a „potem się zobaczy”.
Są też miejsca, w których zamknięty komponent jest po prostu rozsądniejszy. Bramka płatnicza z certyfikatami, mapa z umową na geokodowanie, silnik faktur, który dostawca aktualizuje pod przepisy. Open source nie jest obowiązkiem ideowym. Jest narzędziem. Tam, gdzie narzędzie nie ma opiekuna, a stawka błędu jest wysoka, płaci się za produkt z umową.
Excel, gotowy program czy własny panel z jawną listą paczek
Nie każdy problem wymaga własnej aplikacji. Kilkadziesiąt pozycji i jeden cennik utrzyma arkusz, jeśli jedna osoba go pilnuje i nikt nie trzyma drugiej, „prawdziwszej” kopii w telefonie. Standardowa rezerwacja, standardowa faktura, standardowy magazyn — gotowy program w abonamencie bywa tańszy w utrzymaniu niż własny kod, nawet jeśli ten kod stoi na darmowych bibliotekach.
Własny panel ma uzasadnienie, gdy proces jest nietypowy: indywidualne cenniki, próg rabatu od asortymentu, rezerwacja stanu przy ofercie, faktura z tego samego dokumentu. Wtedy wizytówka albo WordPress może wystarczyć na stronę firmy, a praca sprzedawcy i magazynu i tak wymaga aplikacji, nie motywu. Open source jest w tej aplikacji materiałem. Produktem jest obieg zamówienia.
GESOFT buduje takie panele, gdy gotowiec nie ogarnia procesu. Rozmowa zaczyna się od tego, kto wystawia ofertę, skąd bierze cenę i co ma się stać, gdy stan się nie zgadza. W tym samym zleceniu da się zrobić inwentaryzację zależności: spisać paczki, sprawdzić licencje, zaplanować aktualizacje i nie wciągać do produkcji biblioteki, której nikt nie utrzyma.
Czasem wystarczy integracja istniejącego programu księgowego z panelem zamówień i porządek w lockfile. Czasem trzeba wymienić jedną porzuconą bibliotekę i zostawić resztę. Czasem dopiero po rozpisaniu obiegu widać, że arkusz nadal wystarczy, jeśli rabat liczy jedna osoba, a nie kilkanaście. Taka rozmowa jest tańsza niż przepisanie panelu „bo open source jest ryzykowne” albo „bo zamknięty stos jest poważniejszy”.
Wniosek z argumentów jest wąski. Open source w oprogramowaniu dla firm jest racjonalnym punktem wyjścia na warstwach towarowych. Jest złym substytutem właściciela, umowy i rytmu aktualizacji. Hurtownia z przykładu nie potrzebuje ideologii. Potrzebuje listy tego, co siedzi w panelu, decyzji, które paczki zostają, i osoby, która w następnym kwartale znów tę listę otworzy. Bez tej listy darmowa licencja nic nie mówi o tym, czy jutro da się wystawić ofertę.
Najczęściej zadawane pytania
- Czy firma może legalnie używać open source w panelu B2B?
- Tak, o ile przestrzega licencji konkretnej paczki. Licencja permisywna zwykle pozwala budować zamknięty panel. Licencja copyleft może wymagać oddania odbiorcy tych samych wolności, zwłaszcza gdy kod jest rozpowszechniany albo — przy niektórych licencjach — udostępniany sieciowo. To nie zastępuje porady prawnej w konkretnej umowie.
- Czy trzeba publikować kod własnego panelu, bo siedzą w nim biblioteki open source?
- Nie automatycznie. Wiele popularnych licencji tego nie wymaga przy zwykłym użyciu na serwerze firmy. Wymaganie publikacji zależy od licencji i od tego, czy oprogramowanie jest rozpowszechniane. Dlatego w rejestrze zależności licencja stoi obok nazwy paczki, a nie w ogólnym haśle „wszystko darmowe”.
- Kiedy lepiej kupić zamknięty komponent zamiast biblioteki open source?
- Gdy warstwa jest krytyczna, a firma potrzebuje umowy, czasu reakcji i kogoś, kto odbierze zgłoszenie — typowo baza, bramka płatnicza, mapa, silnik dokumentów pod przepisy. Bibliotekę do wykresu w raporcie wewnętrznym zwykle da się wymienić. Pomocnika płatności bez wydań — raczej trzeba wymienić albo kupić produkt z utrzymaniem.
Powiązana usługa:
Dedykowane oprogramowanie dla firm
Opisz projekt