Ubiegłoroczne decyzje biznesowe Sun Microsystems, Borlanda, Novella, Microsoftu i Oracle'a mogą mieć ogromny wpływ na rynek narzędzi programistycznych.

W 2006 r. na rynku związanym z oprogramowaniem narzędziowym miało miejsce przynajmniej kilka ciekawych wydarzeń, które mogą mieć istotny wpływ na jego rozwój w najbliższych latach. Najważniejsze to uwolnienie kodu Java, wydzielenie firmy CodeGear z Borlanda, umowa o współpracy między Novellem a Microsoftem oraz decyzja Oracle'a o udostępnieniu profesjonalnego wsparcia dla Linuxa.

Wolna Java

Najważniejszym z wydarzeń była chyba decyzja Sun Microsystems o tzw. uwolnieniu Javy, tzn. opublikowaniu pełnej specyfikacji oraz implementacji na zasadach licencji GPL2. GPL2 pozwala komuś, kto wszedł w posiadanie oprogramowania, dowolnie je modyfikować i prowadzić dalszą dystrybucję jedynie pod warunkiem udostępniania i rozpowszechniania kodu źródłowego. Podobnie w przypadku użycia kodu GPL we własnej aplikacji licencja wymaga, by jej kod źródłowy został także publicznie udostępniony.

Zdaniem Suna, siłę Javie ma dać masa użytkowników, a środowiska programistów od wielu już lat postulowały otworzenie specyfikacji i implementacji Javy. Niewątpliwie Sun liczy też, że dzięki przyjaznej licencji Java stanie się elementem każdej dystrybucji Linuxa, pełniąc rolę jądra, wokół którego budowane będą konkretne rozwiązania.

Należy zauważyć, że z taką decyzją zdecydowanie nie zgodził się dr Graham Hamilton, wiceprezes i główny architekt J2SE 1.3, 1.4 oraz 1.5, który w tydzień po jej ogłoszeniu zrezygnował z pracy w tej firmie. Przed odejściem z Suna Graham Hamilton przez 11 lat zajmował się planowaniem oraz opracowywaniem różnych mechanizmów ułatwiających programowanie w Javie i był uważany za głównego adwokata idei zachowania zgodności w środowisku Java, i to za wszelką cenę. Na przykład był jedną z osób, które zdecydowały, że typy ogólne wprowadzone w wersji 1.5 nie wymagały zmiany kodu JVM - mimo że odbyło się to kosztem mniejszej wydajności. Warto podkreślić, że udostępnienie Javy na licencji GPL nie wpływa, przynajmniej na razie, na proces JCP i mechanizmy tworzenia standardów branżowych w świecie Javy. W pracach JCP uczestniczy wiele firm oraz środowiska programistów systemów operacyjnych. Co prawda zdarzają się pewne rozgrywki między członkami komitetu, ale generalnie, z reguły wybierane jest rozwiązanie uznane za najlepsze.

W ciągu ostatnich 3 lat coraz większy udział w przygotowywaniu bibliotek Javy mają środowiska open source, a zwłaszcza projekty przygotowywane pod szyldem Apache Foundation. Mimo że nie były one standardem w sensie JCP, to zyskały tak dużą popularność, że stały się standardem de facto. Jest też co najmniej jeden przykład, gdy rozwiązanie opracowane przez niezależną firmę BEA początkowo nie zostało zaakceptowane przez JCP, ale było dobrze przyjęte przez Apache - tak powstał projekt Beehive, czyli framework ułatwiający tworzenie aplikacji J2EE, bazujący na koncepcji adnotacji i modelu lekkich kontrolek. W efekcie po pewnym czasie projekt ten powrócił do JCP w celu dokonania formalnej standaryzacji. Także z tego punktu widzenia formalne otworzenie Javy jest dosyć naturalnym ruchem.

Tym, czego najbardziej obawiają się przeciwnicy otwarcia Javy, jest realne zagrożenie, że powstanie wiele niezgodnych implementacji Javy. Z jednej strony należy bowiem pamiętać, że środowisko open source nie opracowało stabilnego ABI/API kernela lub innych bibliotek systemowych, które by zachowywały wsteczną zgodność. Zadania tego podejmują się jedynie twórcy dystrybucji Linuxa, tacy jak Novell lub RedHat, którzy zgodnie z polityką ustalaną z klientami starają się zachować zgodność, ostrożnie wprowadzając kolejne poprawki i modyfikacje do oferowanych systemów.

W przypadku Javy jedną z podstawowych zalet tego środowiska jest jego jednolitość i zgodność. Choć trzeba przyznać, że zasady migracji między IBM WebSphere a BEA WebLogic opisywane są w ponad 1000-stronicowym dokumencie. Wynika to z tego, że co prawda producenci na pewnym podstawowym poziomie, wyznaczanym przez stosowny standard J2EE, implementują analogiczne funkcjonalności, ale każdy z nich dodaje także własne i oferuje dodatkowe biblioteki. Podobnie jest z niektórymi mechanizmami konfiguracyjnymi, o których standard nic nie mówi. I tak naprawdę fakt otworzenia samej Javy nie ma tu większego znaczenia. Po udostępnieniu licencji GPL każdy Javę może zmienić i ulepszyć, pozostaje jednak pytanie, czy możliwość ta będzie na tyle atrakcyjna, by przyciągnąć wielu programistów.

Inna jest sytuacja w przypadku Javy "przenośnej", przeznaczonej dla urządzeń mobilnych, głównie telefonów komórkowych. Telefony te mają bardzo różne możliwości i konstrukcje. Do tego pojawiają się błędy w implementacji bibliotek, a czasami nawet bazowej maszyny wirtualnej oraz istnieje wiele tzw. profili J2 ME. Dlatego też okazuje się, że nawet proste gry z reguły są kompilowane pod jeden docelowy model lub markę telefonu. W tym momencie producent telefonu może dowolnie dostosować Javę do potrzeb danego urządzenia, a konieczność udostępnienia kodu niewiele przeszkadza - i tak konstrukcja fizyczna jest chroniona patentami.

CodeGear dla Linuxa czy MacOSCiekawe będą dalsze losy "córki" Borlanda - firmy CodeGear. Szefem nowej firmy jest Ben Smith. Swój trzeci kwartał finansowy 2006 r. Borland zamknął z 12, 2 mln USD straty netto, choć firma odnotowała 21-proc. wzrost przychodów do poziomu 82,4 mln USD, z czego większość (54, 7 mln USD) pochodziła ze sprzedaży rozwiązań klasy ALM. Można się zastanawiać, dlaczego nazwa Borland nie została przy dziale produkującym oprogramowanie, a dla firmy sprzedającej szeroko pojęte narzędzia ALM nie poszukano nowego określenia. Może ten podział był raczej pewnego rodzaju gestem mającym zadowolić inwestorów, a CodeGear będzie sprzedawać swoje produkty sugerując, że to nadal jest Borland.

CodeGear chce utrzymać pozycję "największego niezależnego dostawcy narzędzi". Firma ma pracować zgodnie z publicznie ogłoszonymi planami i dotrzymywać obiecanych terminów. Problem w tym, że dla większości dostawców, i to zarówno ze strony Javy, jak i.Net, same narzędzia programistyczne nie są bardzo istotnym źródłem dochodu. Niektóre edycje są rozdawane za darmo, dużo narzędzi dostępnych jest na zasadach open source, a firmy uzyskują dochody z innych źródeł. Natomiast CodeGear ma się utrzymywać ze sprzedaży narzędzi dla deweloperów. Z zapowiedzi wynika, że Delphi ma być dostępne nie tylko na platformie Windows, choć oficjalnie nie padło stwierdzenie, jaki inny system będzie wspierany. Czy będzie to Linux? Borland już miał produkt IDE przeznaczony na tę platformę - Kylix, w którym przeniósł część funkcjonalności Delphi do Linuxa, ale z przynajmniej kilku powodów narzędzie to nie odniosło sukcesu. Być może jednak CodeGear myśli o MacOS, systemie, który de facto wykorzystuje kod pochodzący z BSD. Firma podkreśla jednocześnie, że jej klienci nadal piszą głównie w Win32 i dlatego chce przede wszystkim dla nich wprowadzać nowe narzędzia ułatwiające tworzenie kodu.

Inną ciekawą zapowiedzią jest to, że CodeGear zamierza wspierać języki dynamiczne. Problem w tym, że jak na razie Borland kojarzy się po prostu z Delphi i JBuilder, a wielu programistów Delphi mówi, że nie potrzebuje wsparcia dla .Net, ale natywnego, szybkiego kompilatora 32- i 64-bitowego. Pojawiają się także głosy, że można użyć wersji FreePascal (która jest zgodna z Delphi 7.0), tak by wykorzystać mechanizmy kompilacji na różne platformy, a z Delphi zostawić samo IDE. Konkurencją dla narzędzi CodeGear jest Chrome firmy RemObject. Jest to dodatek do VS.Net oraz kompilator, który potrafi generować kod dla .Net 2.0 oraz dla Mono (język ObjectPascal został rozbudowany o konstrukcje językowe specyficzne dla .Net 2.0).

Może jednak CodeGear zdecyduje się na udostępnienie Delphi środowisku open source, jak zrobił poprzednio z InterBase, tworząc projekt FireBird.

Ostatnio CodeGear zaprezentował nowy pakiet narzędzi JBuilder 2007. Wersja ta bazuje na Eclipse i ma bardzo podobne możliwości co JBuilder 2006, ale pozwala także na korzystanie z bogatych zasobów dodatków innych firm współpracujących z Eclipse. Niestety, w JBuilder 2007 znikła funkcjonalność związana z projektowaniem GUI w Swing (zamiast tego jest Eclipse Visual Editor) i nie ma wsparcia dla J2 ME.

Kiedyś JBuilder był stosunkowo "lekkim" środowiskiem IDE, a jeżeli ktoś teraz szuka takiego narzędzia, będzie to raczej np. IntelliJ IDEA. Z drugiej strony, konkurencją jest MyEclipse oferujące dosyć tani zestaw dodatków, które pozwalają wykorzystać UML, wspierają AJAX, Hibernate itp. Warto też pamiętać, że Sun nadal rozwija NetBeans - środowisko IDE dostępne za darmo wraz z kodem źródłowym.

Oracle: wsparcie czy zagrożenie dla Linuxa?

Kolejnym istotnym wydarzeniem, które w perspektywie czasu może mieć istotny wpływ na ten rynek, jest ogłoszenie przez Oracle'a programu wsparcia dla RedHat Linux i to o takiej samej jakości, jak firma ta oferuje dla baz danych. Zgodnie z zapowiedziami przełączenie się ze wsparcia RedHat na Oracle Network zajmuje mniej niż minutę. Co ciekawsze, zainteresowani tym użytkownicy nie muszą posiadać licencji/umowy wsparcia na samą bazę danych.

Oczywiście w odpowiedzi RedHat wyjaśnia, że klient decydujący się na taki ruch nie będzie korzystał z "wysokiej biznesowej wartości" suportu RedHat, ani nie będzie miał gwarantowanej binarnej zgodności oraz nie skorzysta z systemu certyfikatów sprzętu, ponieważ de facto Oracle udostępni własną dystrybucję. Warto dodać, że baza Oracle jest uruchamiana głównie na dystrybucji RedHat Linux i na tej platformie jest certyfikowana. Oprócz tego po ostatnich zakupach RedHat ma prawie cały stos aplikacyjny (system, serwer aplikacyjny, katalog itp.), ale bez bazy danych. W takiej sytuacji być może RedHat będzie się starał nawiązać współpracę z PostgreSQL - obecnie chyba jedyną "wolną" i w miarę popularną bazą danych. Oracle wykupił wcześniej SleepyCat (twórcę m.in. BerkeleyDB) oraz Innobase - firmę zajmującą się transakcyjnym pojemnikiem używanym przez MySQL.

Ruch Oracle pokazał, że tak naprawdę nie ma dobrego modelu zarabiania na Linuxie. Firma ta świadcząc wsparcie dla Linuxa ma jednocześnie zupełnie inne źródła dochodu. RedHat znalazł się więc w trudnej sytuacji.

Rok 2007 pokaże, na ile klienci zaufają, że Oracle jest w stanie dobrze wspierać użytkowników Linuxa. Warto zwrócić uwagę, że firma ta dotychczas nie zbudowała czegoś w stylu "RedHat Network - sieci dystrybucyjnej poprawek", a uzyskanie pliku z aktualizacją do bazy danych nie jest tak łatwe i natychmiastowe, jak w przypadku systemu już opracowanego przez RedHat lub twórców innych dystrybucji.

Współpraca w ogniu krytyki

Innym istotnym wydarzeniem jest umowa pomiędzy Novellem a Microsoftem, która określa, że firmy razem będą pracować nad "lepszą" współpracą systemów operacyjnych i narzędziami do wirtualizacji. Dodatkowo Microsoft będzie rozdawał kupony na wsparcie Suse Linux i gwarantuje, że nie będzie pozywał użytkowników Novell SuSE o naruszenie patentów.

W umowie nie jest wyszczególnione, których patentów i jakich modułów dotyczy to zapewnienie, ale niektóre rozwiązania są ewidentnie skopiowane ze świata Windows, jak chociażby elementy Mono - zwłaszcza związane z WinForms lub Samba. Mono jest dla Novella bardzo istotnym elementem, który ułatwia tworzenie rozwiązań dla Linuxa, a przy okazji daje nadzieję na migrację rozwiązań .Net z Windows. Z kolei Samba implementując podzbiór funkcjonalności systemu CIFS pozwala w łatwy sposób udostępniać pliki klientom Windows.

Warto wyjaśnić, że Mono składa się z dwóch elementów. Podstawowy bazuje na standardzie ECMA i w zasadzie wystarcza, by wykorzystując koncepcje .Net tworzyć aplikacje dla Linuxa (na tej bazie powstał np. bardzo ciekawy projekt GTK#, pozwalający projektować interfejs graficzny dla Gnome). Jednak ta funkcjonalność nie wystarczy do migracji rozwiązań z Windows. Tu konieczna jest implementacja ASP.Net lub WinForms. Novell mówi, że dzięki umowie z Microsoft może bez przeszkód kontynuować prace nad Mono.

Otwarte pozostaje jednak pytanie - co będzie, jeżeli ktoś zechce skorzystać z Mono na platformie RedHat.

Umowa z Microsoftem daje szansę, by SuSE Linux lepiej współpracował ze światem Windows i miał lepsze mechanizmy wirtualizacyjne niż inne dystrybucje Linuxa. Jednak licencje open source są tak skonstruowane, że trudno zamknąć jakieś rozwiązanie tylko w jednej dystrybucji. Jeżeli Novell zainwestuje w XEN, to efekt tej inwestycji będzie dostępny także dla RedHat i odwrotnie. Umowa Novella z Microsoftem sprawiła, że firma ta została ostro skrytykowana w zasadzie przez wszystkie środowiska open source. Większość liczy jednak, że kolejna wersja umów licencyjnych GPL3 zablokuje możliwości zawierania takich porozumień.