Hummi CMS • Vendor Lock-in • JSON • PSR-4 • Export Path

Autorski CMS nie musi oznaczać
uzależnienia od wykonawcy.

Vendor lock-in nie wynika z tego, że system jest autorski. Wynika z tego, że dane są zamknięte, kod jest nieczytelny, a ścieżka wyjścia z projektu nie została zdefiniowana.

Hummi CMS rozwiązuje ten problem na poziomie architektury: dane projektu są przechowywane w JSON, kod silnika opiera się na standardowym PHP 8+ OOP, a klient ma do dyspozycji zdefiniowane ścieżki przejęcia lub migracji.

Zobacz model wyjścia Wróć do dokumentacji Hummi CMS
Format danych JSON • otwarty standard
Kod silnika PHP 8+ OOP • PSR-4
Ścieżki wyjścia Licencja lub eksport statyczny
Na czym polega problem

Największym problemem nie jest autorskość systemu. Problemem jest zamknięty model danych.

Wiele autorskich CMS-ów budzi uzasadnioną nieufność, ponieważ klient nie posiada realnej kontroli nad treścią, strukturą projektu ani możliwością zmiany wykonawcy. Dane bywają zapisane w prywatnym formacie, kod nie daje się łatwo przejąć, a migracja oznacza kosztowne przepisywanie wszystkiego od zera.

Hummi został zaprojektowany inaczej. Wyjście z systemu nie jest sytuacją awaryjną, lecz przewidzianym scenariuszem technicznym.

Model zamknięty vs model Hummi
Obszar
Model zamknięty
Hummi CMS
Dane treści
Dane zapisane w prywatnym modelu zależnym od konkretnego panelu lub dostawcy.
Dane projektu przechowywane w JSON — otwartym standardzie czytelnym dla każdego środowiska.
Kod
Kod trudny do przejęcia, zależny od niejawnych mechanizmów i dokumentacji autora.
Silnik napisany w PHP 8+ OOP, z namespaced klasami i autoloadingiem zgodnym z PSR-4.
Migracja
Migracja wymaga zwykle ręcznego rozbrajania panelu i rekonstrukcji treści od zera.
Projekt może zostać wyeksportowany do statycznego HTML/CSS/JS wraz z danymi JSON albo rozwijany dalej na podstawie pełnej licencji.
Zmiana wykonawcy
Zmiana wykonawcy bywa blokowana przez format danych, model licencji lub prywatną architekturę.
Inny programista może przejąć projekt na poziomie danych, kodu lub eksportu statycznego.
Panel i design
Często silnie związane ze sobą, co utrudnia separację danych od warstwy prezentacji.
Panel zarządza danymi, a nie layoutem. Ułatwia to migrację i zachowanie czystego modelu treści.
Ścieżka wyjścia
Często nieopisana, nieprzetestowana albo zależna wyłącznie od dobrej woli wykonawcy.
Zdefiniowana operacja techniczna: wykup pełnej licencji lub eksport projektu do niezależnego szablonu statycznego.
Dane i kod
Otwartość modelu

JSON rozwiązuje problem danych. Standardowy PHP rozwiązuje problem kodu.

Hummi rozdziela dwa obszary, które najczęściej generują lock-in: model danych i warstwę wykonawczą. Treści są przechowywane w JSON, czyli w formacie, który można odczytać, przetworzyć i zaimportować w dowolnym innym stacku.

Kod silnika nie opiera się na prywatnym, nieczytelnym mechanizmie. To PHP 8+ z podziałem na klasy, metody i namespaces, dzięki czemu inny programista może przejąć projekt bez odgadywania, jak działa rdzeń systemu.

JSON PHP 8+ Namespaces PSR-4 OOP Portability
Dane
  • otwarty format JSON,
  • czytelność dla PHP, JS i innych środowisk,
  • łatwy import i eksport,
  • brak prywatnego modelu danych.
Kod
  • PHP 8+ OOP,
  • classes / methods / namespaces,
  • autoloading zgodny z PSR-4,
  • przewidywalna struktura do przejęcia i audytu.
Ścieżki wyjścia
Zdefiniowane scenariusze

Wyjście z systemu jest procesem technicznym, a nie problemem negocjacyjnym.

Jeśli klient chce kontynuować rozwój bez ograniczeń po stronie wykonawcy, może wykupić pełną licencję Hummi wraz z prawami do dalszego utrzymania i rozwoju.

Jeśli celem jest całkowite odejście od silnika, projekt może zostać wyeksportowany do czystego HTML/CSS/JS wraz z danymi JSON. Taki model pozwala zachować treść, strukturę i frontend, a jednocześnie uniezależnić wdrożenie od dalszego działania Hummi jako runtime.

Wykup licencji Eksport statyczny HTML/CSS/JS JSON export Migration path
Ścieżka 1

Wykup pełnej licencji
Klient nabywa prawa do dalszego rozwoju i może kontynuować pracę z dowolnym programistą.

Ścieżka 2

Eksport projektu
Projekt przechodzi do czystego HTML/CSS/JS wraz z danymi JSON i przestaje być zależny od runtime Hummi.

Efekt

Klient nie zostaje z zamkniętym środowiskiem bez wyjścia. Zależność od jednego wykonawcy nie jest wpisana w model działania systemu.

Wniosek

Vendor lock-in nie jest cechą autorskiego CMS-u. Jest cechą złego modelu wyjścia.

Hummi CMS eliminuje lock-in przez otwarty format danych, czytelną architekturę kodu oraz dwie zdefiniowane ścieżki przejęcia lub migracji projektu.

Najważniejsza różnica

W Hummi klient nie musi ufać deklaracji „da się to kiedyś przenieść”. Model wyjścia został przewidziany na poziomie architektury i procesu wdrożeniowego.

Powiązane materiały
Dokumentacja
Pełna architektura Hummi CMS
Flat-File CMS
Model danych i odczyt bez SQL
Panel
Dane zamiast layoutu
Kontakt
Wdrożenie Hummi CMS

Jeśli chcesz mieć system z realną ścieżką wyjścia

Pokażę, jak wygląda architektura Hummi, jak przechowywane są dane i jakie opcje przejęcia lub migracji projektu pozostają po stronie klienta.

Szybki kontakt

Opisz projekt

Wysyłając formularz, zgadzasz się na kontakt w sprawie zapytania.
Szczegóły znajdziesz w Polityce prywatności.