Progress zawsze wierny 4GL

Z Joe Alsopem, założycielem i prezesem Progress Software, rozmawia Marian Łakomy.

Z Joe Alsopem, założycielem i prezesem Progress Software, rozmawia Marian Łakomy.

Pańska firma oferuje szeroką gamę produktów: narzędzia programistyczne, środowisko do osadzania aplikacji, bazy danych. Jak definiuje Pan misję Progress Software?

Misją firmy jest dostarczanie narzędzi osobom odpowiedzialnym za tworzenie, instalowanie i utrzymywanie aplikacji. Oferujemy wszystko, czego potrzebuje profesjonalny programista.

Przedstawiciele Progressa widzą przyszłość rynku oprogramowania w wynajmowaniu aplikacji w modelu ASP (Application Service Provider). Nie sądzi Pan, że gdy twórca aplikacji zacznie je wynajmować, straci podstawowe źródło dochodu pochodzące z tradycyjnej sprzedaży?

Oczywiście, że takie ryzyko istnieje. Promując ASP, rozważamy wady i zalety tego modelu. Zrozumiałe jest, że firma - przechodząc na model ASP - osiągnie korzyści tylko wtedy, gdy ewentualny spadek tradycyjnej sprzedaży aplikacji zrekompensuje jej odpowiednia liczba zawartych umów wynajmu. Docierają do nas sygnały, że wielu naszym partnerom udało się zawrzeć umowy najmu z klientami, którzy dotychczas nigdy nie kupili aplikacji. Oczywiście nie udaje się to wszystkim.

Od pewnego czasu coraz więcej mówi się o usługach sieciowych - Web services. Co Pan sądzi o tym zjawisku?

Usługi sieciowe istniały od początku Internetu: użytkownik tego medium zawsze mógł zażądać dostarczenia notowań giełdowych czy prognozy pogody. Współczesne usługi sieciowe można łączyć z aplikacjami za pośrednictwem interfejsów programistycznych. Sądzę, że Web services zaczną odgrywać coraz ważniejszą rolę, gdyż będą mogły z nich korzystać do pobierania danych lub wykonywania określonych funkcji, których nie opłaca się realizować na komputerze lokalnym.

Nasza firma wspiera standardy zapewniające współpracę aplikacji opartych na technologii Progressa z usługami sieciowymi. W tym zakresie pomocny może się okazać pakiet do komunikacji asynchronicznej SonicMQ, gwarantujący dostawę komunikatów między aplikacją a usługą.

Jak Progress działa w tzw. ruchu otwartego kodu?

Jestem zagorzałym zwolennikiem otwartego kodu. Nie uważam jednak, że jego zaletą jest to, iż oprogramowanie jest dostępne za darmo.

Często nasi klienci przychodzą z pomysłami, jak zmienić dany produkt zgodnie z ich potrzebami. Napięte harmonogramy nie zawsze pozwalają nam to wykonać. Możliwość wprowadzania przez klienta zmian do naszego produktu jest bardzo cenna i ważna. W ramach programu POSSE udostępniamy kod niektórych narzędzi. Dzięki temu wielu partnerów stworzyło własne narzędzia programistyczne, lepiej dostosowane do ich potrzeb. Najlepsze z tych rozwiązań wykorzystujemy.

Unikatową cechą oferty Progressa w dziedzinie otwartego kodu jest fakt, że zarówno aplikacje, jak i narzędzia są tworzone za pomocą tego samego języka 4GL. Modyfikując narzędzie nie trzeba przechodzić na C++ czy Javę. Nasz partner używa języka programowania, który już dobrze zna.

Jak przedstawia się strategia Progressa wobec Javy?

Widzę tu dwa aspekty. Pierwszy dotyczy języka programowania. Przechodzenie z 4GL na Javę przy tworzeniu aplikacji nie zapewnia wzrostu wydajności twórców aplikacji, jakiego oczekiwaliśmy jeszcze 3 lub 4 lata temu. Dlatego pozostajemy przy 4GL.

Drugi aspekt to zbiór standardów Java do współpracy między aplikacjami w Internecie. Dotyczy to zarówno komunikacji między aplikacjami poprzez JMS, jak i komponentów EJB współpracujących ze sobą poprzez sieć. Dowolny komponent opracowany w 4GL może być osadzony na serwerze aplikacyjnym jako komponent EJB. Progress wspiera standardy J2EE.

W Internecie nie da się z góry określić liczby użytkowników. Wiele firm decyduje się wyceniać swoje produkty - bazy danych i serwery aplikacyjne - wg liczby lub mocy procesorów komputera, na którym one działają. Progress pozostaje przy modelu wyceny według liczby użytkowników. Dlaczego?

Stosowaliśmy już model płatności według liczby procesorów komputera, ale na życzenie naszych klientów przeszliśmy na wycenę według liczby użytkowników. Wynikało to głównie z faktu, że tradycyjny model był tańszy dla użytkownika końcowego.