Czy warto tworzyć własnego CMSa?

Ostatnio znacząco zweryfikowałem swoje spojrzenie na narzędzia, jakim są Systemy Zarządzania Treścią (CMS) na stronach www. Narzędzie, bez którego żadna szanująca się witryna nie może się obecnie obejść.

W czasach kiedy zaczynałem przygodę z internetem (połowa lat ’90) nikt jeszcze nie marzył o takich narzędziach. Łączenie się z Internetem modemem skutecznie utrudniało ich wygodne użytkowanie, co wstrzymywało powstanie takich aplikacji. Strony www budowało się na dwa sposoby:

– edytorem wizualnym (np. FrontPage),
– edytorem tekstowym (np. Notatnik).

Ci uważani za lepszych pisali strony „z palca” w edytorach tekstowych, ja osobiście lubiłem usprawnić sobie pracę i stosowałem kombinację powyższych metod z lekkim wskazaniem na „wizualność”.

Wraz z wzrostem szybkości połączenia do sieci, jak i rozwojem technik dynamicznego programowania serwerów (PHP, Ajax) nadszedł czas przeniesienia edycji treści strony www na strony www 🙂 Początkowo były to narzędzia bardzo prymitywne, zwykłe pola do wstawienia treści. Jej formatowanie np. dodanie pogrubień robiło się w HTMLu wtrącanym w treść. Z czasem powstały pierwsze wizualne edytory osadzana na stronach www.

W tych też czasach, czując powiew nowego, wraz z znajomymi, najpierw powoli nieśmiało, dla własnych potrzeb, stworzyliśmy CMSa. Narzędzie to o dziwo do dzisiaj obsługuje serwis UFO Info mając prawie 10 lat. Zachęceni tym, postanowiliśmy dalej go rozwijać oferując go klientom. Był to system instalowany wraz z wdrożeniem na serwerze u klienta. Instalacja była niczym innym jak zwykłym wgraniem plików php na serwer i połączeniem tego z bazą MySQL. Dlatego też zwaliśmy tego CMSa plikowym.

Okazało się z czasem, że każdy kolejny klient otrzymywał coraz bardziej rozbudowaną wersję systemu. Pojawiły się też pierwsze problemy. Nowe dodatki do CMSa wcale tak łatwo nie szło dodać do jego starszych wersji gdy klient poprosił o aktualizację. Przy każdym wykrytym błędzie,poprawki trzeba było ręcznie instalować na każdej zainstalowanej instancji, pamiętając czym się od siebie różniły. Aż do dnia kiedy dostaliśmy zamówienie do wdrożenia w krótkim czasie prawie 400 CMSów… To była jazda na sankach pod górkę…

I tak potrzeba urodziła myśl, czy można zrobić jednego CMSa, jeden silnik, w jednym miejscu obsługujący wiele stron klientów o różnych wyglądach? Nazwaliśmy to coś roboczo multi CMS. A równolegle świat uknuł na takie aplikację nazwę SaaS (Software as a Services). Po kilku miesiącach pracy był gotowy. Wreszcie dodanie nowego klienta to było tylko stworzenie w Panelu nowego użytkownika. Wreszcie naniesienie aktualizacji czy poprawki było w jednym miejscu i od razu wszyscy użytkownicy to mieli. Zmniejszyło to ilość naszych nakładów pracy. Zrobiło się wygodnie. Dodatkowo spokojnie szło konkurować a nawet być o kroczek z przodu w możliwościach CMSa z powstającymi CMSami w świecie Open Source jak WordPress czy Mambo.

Pierwsze problemy pojawiły się wraz z mocno zróżnicowanymi prośbami klientów o rozbudowę. Często mocno specyficzną dla danego klienta. A my przecież dodając jakąś funkcję jednemu dodamy to wszystkim. Dodatkowo, życie pokazało, że nawet najmniejsza awaria CMSa była sporym zamieszaniem gdyż rzutowała momentalnie na wszystkich użytkowników. Rosnąca liczba użytkowników, ich indywidualnych potrzeb oraz wymogów dla wydajności programu stawała się coraz większym zmartwieniem. Jedna mała zmiana w wyświetlaniu strony www tworzonej przez CMSa wymagała by wszyscy graficy lub ludzie od CSS każdego klienta z osobna mieli co robić. Słowem jak ognia unikaliśmy zmian które wprost rzutowały na to co wypluwał na ekran przeglądarki CMS.

Dodatkowym problemem, który na szczęście tylko kilku klientów odczuło, były problemy z „programistami”. Ich chwilowy brak lub niesolidność przekładały się na tempo zmian lub jakość kodu. Klient tego nie wie, nie czuje, jak stoi firma z której wykorzystuje ich autorskiego CMSa. Dział marketingu sprzeda wszystko 🙂 A co jak taka firma ma problem lub upadnie? Kto zadba o takiego porzuconego CMSa? A są CMSy w których klient nie ma dostępu w ogóle do plików i kodu by próbować samemu się ratować.

Znam wiele dobrych firm, które oparły swój byt o CMSy firm od budowy stron. CMSy, których poza twórcami nikt nie zna od strony kodu i często nikt poza nimi nie ma do niego dostępu. Takie małe drużyny: grafik + programista PHP. A co jak takiemu programiście się nagle odwidzi? Albo zginie w wypadku? Co ten biedny grafik zrobi jak nie zna się na kodowaniu? A tu dodatkowo się okaże, że nie było dokumentacji do kodu wyjaśnieniem co która procedura robi. Albo jak taka ekipa zwinie się z rynku? Klient nagle się szybko uświadomi jak na dużej bombie z opóźnionym zapłonie siedział… A co jak klient zechce zmienić firmę obsługującą? Często za tym idzie zmiana CMSa. I budowa od nowa.

Dość powiedziałem. Nie chcę takiego ryzyka dla klientów. Dodatkowo widziałem jak świat Open Source te setki tysięcy programistów z całego świata, rozbudowali swoje CMSy. Chcąc nie chcąc nie było szans, tak szybko i tak sprawnie, swoimi siłami, śledzić trendy i rozbudowywać CMSa. Po co, skoro to wszystko jest już gotowe na wyciągnięcie ręki?

Weźmy takiego WordPressa będącego najpopularniejszym CMSem świata. Świetny silnik, setki gotowych wtyczek rozbudowujących go o dodatkowe wyrafinowane funkcje, tysiące szablonów i wreszcie miliony użytkowników, ludzi którzy mogą pomóc. To nie zniknie z dnia na dzień ot tak, jak może zniknąć mała firma z własnym CMSem.

Klient któremu robimy stronę www wie, że dostaje taki a taki otwarty popularny system CMS. Wie, że jak nie my to z łatwością znajdzie ludzi do serwisowania czy rozbudowy. Dostaje do wszystkiego dostęp.

Uważam, że dziś już nie warto tracić czas i tworzyć własnego CMSa. Gotowe i bardzo dobre narzędzia już istnieją. Tylko je brać, dostosowywać, wdrażać i używać. Klient chce integrację z Facebookiem lub YouTube? Tak by wrzucając film na YT z automatu film był też na jego stronie www? Proszę bardzo gotowych wtyczek jest kilkanaście. Zanim przeryjesz dokumentację integracji z You Tube i napiszesz własne rozwiązanie, ja zdążę wyjechać i wrócić opalony z wakacji 🙂

Nie warto tracić czasu na pisanie własnego CMSa mając w Internecie takie bogactwo gotowych aplikacji i co ważne wsparcie.