W trakcie prow adzenia za jęć o różnorodnych system ach inform acyjnych au torka przeprow adzała w yw iad y ze studentam i, które m iały na celu zebranie opi nii o prezentowanym oprogram ow aniu, m .in. o oprogram ow aniu FLOSS. Sondaż opierał się na pytaniach zadaw an ych w trakcie zajęć. Dotyczyły one funkcjonalno ści system ów, ich użyteczności, w ad i zalet w ykorzystyw ania konkretnych aplika cji oraz reakcji studentów, jako użytkowników, na staw ian e im w trakcie ćwiczeń za d an ia do w ykonania. Z a d an ia te dotyczyły podstawowych funkcji: w yszukiw a nia inform acji, w pro w adzan ia i m odyfikowania danych, tw orzenia raportów, opcji w ypożyczania dokumentów o raz zm ian adm inistracyjnych: dostosowywaniu w y glądu interfejsu, u staw iania zasadniczych kryteriów (grup użytkowników, przedsta wianych baz, u staw iania zasad dostępu do danych, drukowania spraw ozdań itp.), przygotow yw ania specyficznych raportów itp.
N a podstawie odpowiedzi studentów przygotowano poniższe zestaw ienie naj w ażniejszych cech aplikacji, które były oceniane zarów no pozytywnie, ja k i nega tyw nie. C e ch y te pogrupowano w kategorie: ekonom iczne, czasow e (w znaczeniu: dotyczące czasu) i funkcjonalne, chociaż nie je st to podział rozłączny. C zę ść w łaści wości system ów mogła zn aleźć się we w szystkich kategoriach (np. opracow ane no we funkcjonalności, na których przygotowanie trzeba m ieć czas i pieniądze), lecz
dla spójności rozdziału omówione zostały tylko raz. N a zakończenie an alizy prze stawiono też w ad y i za lety im plem entacji dla jednej instytucji oraz dla konsorcjum. Jako pierwsze przedstaw ione zostaną kategorie poszczególnych cech.
3 .1 . Kategorie
3 .1 .1 . K a te g o rie e k o n o m iczn e
W a żn ą cechą, zaw sze podkreślaną przy analizie o program ow ania FLOSS jest jego „taniość". O czyw iście ten brak kosztów odnosi się w yłącznie do braku opłat licencyjnych, a nie do braku opłat w ogóle. Studenci zau w ażali m echanizm y po bierania opłat np. za dodatkowe biblioteki oprogram ow ania wolnego, tworzenie struktu r baz, dostosowywanie interfejsów itp. Stw ierdzali także, iż instytucja, któ ra chciałab y zaim plem ento w ać takie aplikacje, musi przeprow adzać w iele zm ian, także kosztownych. Po pierwsze musi zatrudn ić lub doszkolić inform atyków, którzy będą pracow ać przy wdrożeniu i rozbudowie o program ow ania (np. stw orzeniu no wych modułów, spolszczeniu itp.). Może się też okazać, iż trzeba zatrudn ić nowych bibliotekarzy, którzy będą służyć pom ocą m erytoryczną oraz będą w prow adzać do system u ogólne i szczegółowe dane (słowniki, pojedyncze inform acje o zbio rach, użytkownikach itp.). Biblioteka na pewno powinna też w szystkich pracowni ków przeszkolić, co oznacza kolejne w ydatki.
Do tych uwag studenci dodaw ali kolejne. C zę ść bibliotek już skom puteryzowa nych wykorzystuje oprogram ow anie w yłącznie do tw orzenia opisów bibliograficz nych o strukturze nierelacyjnej, część tw orzy relacje np. w związku z w ykorzysty w aniem rekordów KH W . N iektóre jednostki o pracow ują bardzo różnorodne typy dokumentów, nie tylko książki i czasopism a, co oznacza w ielorakie struktu ry da nych. Do tego dochodzą instytucje posiadające zautom atyzo w an ą w ypożyczalnię, a w ięc dysponujące bazam i z rekordam i użytkowników. Trudno w ięc a p rio ri zało żyć w szystkie możliwe procedury, które należy przygotować dla tak wielu różnorod nych obiektów. M ożna założyć ogólny model, który za każdym razem w ym ag a do praco w ania i sperso nalizow an ia. A to oznacza dalsze koszty.
W nioskiem z tych uwag je st stw ierdzenie, iż aplikacje FLOSS, ja k każde inne, w ym ag a ją dostosow ania do potrzeb konkretnej instytucji. W sytuacji gdy biblio teka otrzym uje kod źródłowy, jej zadaniem staje się przygotowanie adekwatnego dla niej i jej użytkowników interfejsu (przede wszystkim zad b an ie o funkcjonalność i estetykę, np. przez dostosowanie go do ogólnie przyjętej identyfikacji jednostki). Przy wielu program ach konieczne je st ich spolszczenie. Do tego dochodzą kolej ne koszty zain stalo w an ia system u, np. an aliza istniejących struktur, ich rozbudo w a lub stw orzenie od nowa, spolszczenie nazw pól, o pracow anie relacji itp. W a ż ne je s t przygotowanie słowników, które obow iązyw ać będą w konkretnym system ie
(haseł wzorcowych, słów kluczowych itp.). Istotną kwestią są również możliwości aplikacji w zględem im portów i eksportów danych z w łasnych oraz ogólnie dostęp nych system ów. W pewnych przypadkach trzeba cały taki moduł stw orzyć od no w a, aby dobrze pobierać rekordy np. z baz centralnych. Je st to zarów no problem aplikacyjny, ja k i m erytoryczny: dostosow ania danych m iędzy sobą. Trzeba więc przede wszystkim dobrze „zm apow ać" pola. Do tego dochodzi cena przygotowa nia plików pomocowych dla użytkowników, aby mogli oni sam i w ykorzystyw ać no we aplikacje. Może się też okazać (i często ta k się okazuje), iż trzeba zakupić no w y sprzęt albo go zm odernizow ać. Pam iętać też należy o niezbędnych nakładach na sta łą eksploatację bazy (utrzym anie se rw era, inform atyka, opłaty za prąd itp.) oraz o je j zabezpieczeniu, zw łaszcza jeśli instytucja przechowuje dane użytkowni ków (firew all itp.).
Studenci, zw łaszcza studiów niestacjonarnych i podyplom owych, podkreślali, iż małych instytucji nie stać na takie w ydatki. Nie zaw sze też łatwo takim instytucjom sta ra ć się o grant. Stąd w iele małych bibliotek, jeśli w chodzą w ja k ą ś sieć, w ybiera aplikacje proponowane przez jednostki nadrzędne lub próbuje tw orzyć w łasne sto w arzyszen ia, aby spróbow ać otrzym ać dofinansow anie dla całej grupy.
Podsum owanie najw ażniejszych za let i problem ów zw iązanych z kryteriam i ekonom icznym i m ożna przedstaw ić w następującej tabeli:
Tabela 1. Kryteria ekonomiczne
Z a le ty zak u p u o p ro g ra m o w a n ia K o szty im p le m e n ta cji
cena oprogramowania zatrudnienie informatyków, bibliotekarzy; koszty szkoleń pracowników
koszt dostosowania programu do wymagań biblioteki (w tym spolszczenia, importów itp.),
zainstalowania, utrzymywania, rozbudowy niezbędne nakłady na stałą eksploatację bazy oraz
jej zabezpieczanie
zakup nowego sprzętu lub jego modernizacja
Źródło: opracowanie własne.
3 .1 .2 . C z a s p o trz e b n y na w d ro ż e n ie sy ste m u
Kolejnym elem entem , który należy brać pod uwagę przy analizie oprogram o w an ia , je s t czas potrzebny na: dostosowanie program u do w ym agań bibliotek, je go zainstalo w an ie, przyuczenie personelu i czytelników oraz w prow adzenie da nych.
Koszty czasow e są - poza finansow ym i - często w skazyw ane przez studentów. C zę ść studentów studiów niestacjonarnych i podyplomowych w skazyw ała w ręcz na niem ożliwe do spełnienia życzenia w ładz jednostek: natychm iastow e urucho
mienie i uzupełnienie danymi nowego opro gram o w ania. A przecież czas na za instalow anie i dostosowanie system u do potrzeb w szystkich użytkowników bywa dość długi: może trw a ć np. rok. N ato m iast „zapełnianie" danymi je s t procesem w ręcz nieskończonym. M ożna go oczyw iście sk ra c a ć poprzez różnego rodzaju im porty. Lecz żaden im port wielu danych nie został ja k na razie przeprowadzony „bezstratnie". D opracow anie m apow ania pól, ustalenie w zajem nych relacji, podję cie decyzji, ja k poprzedni sposób katalogow ania za stąp ić nowym, w ym ag a także czasu. Do tego dochodzi okres „akceptacji" nowego system u przez użytkowników bibliotek, ich przyuczenia, a ze strony jednostki - czas przygotowania pom ocy/hel pów dla czytelników. N ato m iast w sytuacji gdy konkretna biblioteka przyzwyczaiła swoich użytkowników do specyficznych usług, np. przygotow yw ania specyfikacji, bi bliografii tem atycznych itp., dodać jeszcze należy okres im plem entacji tych usług, np. poprzez stw orzenie nowych modułów w system ie.
O czyw istą za letą je st jed nakże zaoszczędzony przez czytelników i pracowników czas, który dla przekazyw ania różnorodnych inform acji skraca się, niekiedy bardzo zn acząco . Nowe funkcjonalności po zw alają użytkownikom system u przygotowy w ać także nowe opraco w ania i analizy, które w cześniej nie były po prostu możliwe. Skraca się w ięc okres tw orzenia nowej wiedzy.
J a k w id ać z przedstawionych uwag, poprzednie tezy w ygłaszane przez studen tów przy an alizie finansow ej odnieść m ożna także do czasu trw a n ia w drożenia oraz eksploatacji aplikacji. Stąd podsum owanie kryteriów dotyczących czasu two rzy dość podobną zakresow o tabelę.
Tabela 2. Kryteria dotyczące czasu
Z a le ty za im p le m e n to w a n ia o p ro g ra m o w a n ia C z a s im p le m e n ta cji czas dostępu do danych zaoszczędzony przez
czytelników i pracowników instytucji
dostosowanie programu do wymagań bibliotek i jego zainstalowanie
nowe funkcjonalności systemu = poszerzenie usług
= krótszy czas tworzenia się nowej wiedzy przyuczenie personelu opracowanie plików pomocy
przygotowanie czytelników wprowadzenie danych
Źródło: opracowanie własne.
3 .1 .3 . F u n k c jo n a ln o ść
Potencjalne problemy, które w stosunku do im plem entacji wolnego oprogram o w an ia zg łaszali studenci, odnosiły się także do cech funkcjonalnych. Podkreślali oni przede wszystkim konieczność takiego dopracow ania aplikacji, aby m ożna było jq ocenić jako przyjazną dla czytelnika i bibliotekarza. O czyw iście część oprogram o w ań ma przygotowane podstawowe funkcjonalności: w prow adzanie, w yszukiw a
nie i prezentację danych. Bardziej sp ecjalistyczne, za aw an so w an e m ożliwości ad m inistrato r bazy musi je d n a k w większości system ów przygotować sam odzielnie. Nie je st to tylko kwestia czasu i pieniędzy, ale także umiejętności i w iedzy m ery torycznej. A b y inform atyk n ap isał oprogram ow anie, sp ecjalista musi przygotować algorytm i zdefiniow ać najw ażniejsze czynności, konieczne do w ykonania zaplan o w anych za d ań . Poza kosztami finansow ym i i czasow ym i w ym aga to w iedzy i umie jętności, zw łaszcza przy dokładnym rozdzieleniu modułów czytelnika, bibliotekarza i ad m in istrato ra. W ażn e dane w ym uszają stw orzenie kilku interfejsów oraz apli kacji zapew n iających bezpieczeństwo. Praca może w ięc zostać „pom nożona przez 3" w zw iązku z trzem a interfejsam i i ap likacjam i w spom agającym i konkretne ele m enty system u.
Kolejne segm enty funkcjonalne problem atyczne dla przyszłych i obecnych bi bliotekarzy to cechy zw iązane z ulokowaniem nowego w olnego/otw artego opro gram o w ania w istniejącym system ie bibliotecznym . W chodzi w to m ożliwość wyko rzystania istniejących baz danych (czyli np. importu danych do nowych baz nowego system u), w ym ian y inform acji z innymi system am i oraz dostosowanie oprogram o w an ia do baz istniejących w poszczególnych bibliotekach (czyli ze zm ian ą aplika cji, aby istniejące bazy m ożna było w ykorzystyw ać). Studenci na przestrzeni lat podkreślali, iż w iele instytucji rozpoczęło katalogow anie dokumentów w form acie M A R C BN . Niektóre mniejsze biblioteki jeszcze nie dokonały pełnych konwersji do form atu M A R C 21. Do tego dochodzi problem baz o strukturach całkow icie od miennych od struktu r M ARC-owskich. Z aliczyć do nich m ożna np. bazy tworzone w bibliotekach publicznych czy kościelnych: o osobach zw iązanych z regionem , baz cytatów, baz pełnotekstowych itp. Nie należy też zapo m in ać o dodatkowych po lach, które zostały stw orzone w poszczególnych jed nostkach, np. dla własnych kla syfikacji, dodatkowych opisów, notatek, streszczeń itp. N aw et jeśli m ożemy wyko rzystać bazy przygotowane w podobnej instytucji, to może okazać się, iż musimy dodać nowe pola, relacje, stw orzyć m apow ania oraz dokonać nowych importów.
Studenci rozw ażali także cechy określone w definicjach i opisach system ów FLOSS. Z a p isa n a wśród nich niezawodność op arta na w spółpracy internautów nie była do końca przekonująca dla studentów, zw łaszcza studiów niestacjonarnych czy podyplom owych. Instytucja publiczna, ja k ą je st biblioteka, nie może liczyć tyl ko na „pospolite ruszenie" internautów. Dostęp dla czytelników musi być za p ew niony zaw sze. W sytuacjach trudnych, aw aryjnych trudno oczekiw ać n atychm iasto wego odzewu społeczności sieci. Nie oznacza to, iż taki nie nastąp i. Problem jest je d n a k z czasem , który upływa od w ystąp ien ia aw arii do ponownego pełnego uru
chom ienia system u.
Kolejna cecha - nieskrępow any i w artki rozwój o program ow ania - w ydała się studentom „fascyn u jąca". U znali taki nurt w spółdziałania za fenom en sieci, cho
ciaż pojaw iały się obaw y o „znudzenie program em ", „w ytworzenie nowego produk tu, nie do końca kom patybilnego", z przerzuceniem na instytucję dbałości o rozwój aplikacji, co niesie za sobą koszty finansow e i czasow e. Studenci w skazali wręcz, iż niezależność od jednego usługodaw cy/firm y dla małej jednostki nie je st zawsze cechą pozytyw ną. Poczucie w sp arcia oraz sam o w sparcie je s t istotne zarów no dla pracowników, ja k i użytkowników biblioteki. W ią za li je często z dobrze funkcjonują cą firm ą , stab iln ą, ro zw ijającą się, tw o rzącą niedrogie aplikacje.
Podsum owując cechy zw iązane z funkcjonalnością, m ożna stw orzyć następu ją c ą tabelę:
Tabela 3. Cechy funkcjonalne systemu
Z a le ty o p ro g ra m o w a n ia F u n k cjo n a ln o ść - p ro b lem y możliwość wykorzystania istniejących baz danych
oraz stworzenia nowych
dostosowanie oprogramowania do baz istniejących w poszczególnych bibliotekach (struktury inne niż
M ARC 21; dodatkowe pola itp.) możliwość wymiany informacji z innymi systemami rozwój systemu
przyjazność dla czytelnika; nowe usługi reakcja na sytuacje awaryjne przyjazność dla bibliotekarza; nowe usługi
potencjalny dynamiczny rozwój (wielu twórców)
Źródło: opracowanie własne.
3 .2 . Jednostki im plem entujące
Kolejny podział zalet i w ad o program ow ania dotyczy liczby jed nostek imple m entujących oprogram ow anie: jednej lub wielu, głównie zrzeszonych w konsorcja. W zależności od liczby w spółpracujących bibliotek inaczej rozkłada się bowiem praca przy im plem entacji i użytkowaniu system u. Tę część rozpoczyna an aliza dla jednej instytucji.
3 .2 .1 . J e d n a in sty tu cja im p le m e n tu ją c a
Do zalet sam odzielnej im plem entacji studenci zaliczyli przede wszystkim do kładne dostosowanie o program ow ania do własnych potrzeb biblioteki - przy moż liwości w ykorzystyw ania rozw iązań instytucji, które zrobiły to w cześniej. W ią że się to oczywiście z w iększym i kosztami finansow ym i i czasow ym i. Do w ad takiego roz w ią za n ia zaliczono: trudności przy instalacji, które niekoniecznie pracow nicy kon kretnej instytucji mogą pokonać, oraz konieczność w ykonania sam odzielnych prac im plem entacyjnych, zm ieniających i poszerzających działanie oprogram ow ania. Może to doprow adzić w ostateczności do w ytw orzenia „podprogram ów", które w porównaniu z innymi im plem entacjam i m ogą okazać się w ręcz nowymi aplika cjam i, mało kom patybilnym i. W takiej sytuacji istnieje też m ożliwość zaistnienia wielu struktur, naw et jeśli zbudow ane są one na zaakceptow anym form acie.
Podsum owując najw ażniejsze p ara m e try oprogram ow ań, przedstaw ić można n astęp ującą tabelę:
Tabela 4. Zalety i wady samodzielnej implementacji
Z a le ty sa m o d z ie ln e j im p le m e n ta cji Tru d n o ści p o w sta ją c e p rzy sa m o d zie ln e j im p le m e n ta cji
wykorzystywanie rozwiązań innych instytucji
trudności przy instalacji; konieczność samodzielnych prac implementacyjnych - wytworzenie „podprogramów",
możliwość zaistnienia wielu struktur stworzenie programu dla potrzeb
konkretnej instytucji
Źródło: opracowanie własne.
3 .2 .2 . K o n so rcju m
W porównaniu z sam o dzielną p racą przy im plem entacji oprogram ow ania FLOSS konsorcjum w ydaw ało się studentom bardziej atrakcyjne. Do za let stw orze nia grupy w spółpracujących instytucji zaliczono: rozłożenie prac m iędzy w iele jed nostek, rozłożenie opłat, o pracow anie wspólnej polityki instalacji i im portów da nych oraz w iększy nacisk na utrzym yw anie przyjętej struktu ry danych. Podkreślano też w iększą pomysłowość wielu pracowników, która może spowodow ać w ytw orze nie nowych usług i lepszą funkcjonalność aplikacji.
Nie zabrakło je d n a k i w ad, do których zaliczono kolejność prac nad ad ap tacją program u dostosow ywaną do potrzeb najliczniejszej grupy zainteresow anej da nym problem em , co może o znaczać, iż biblioteka po siad ająca np. dodatkowe po la może długo czekać na dopracow anie aplikacji specjalnie dla niej. Podkreślano też, iż rozwój system u często zgodny je s t z polityką tw orzoną przez lidera, najm oc niejszego w konsorcjum.
Zebrane w tabelę przym ioty aplikacji zaprezentow ać m ożna następująco:
Tabela 5. Zalety i wady implementacji konsorcjalnej
Z a le ty im p le m e n ta cji k o n so rcja ln e j Tru d n o ści p o w sta ją c e p rzy im p le m e n ta cji ko n so rcja ln e j
rozłożenie prac między wiele instytucji
kolejność prac adaptacyjnych dostosowana do potrzeb najliczniejszej grupy zainteresowanej
danym problemem (lub zgodna z polityką tworzoną przez lidera) opłaty rozłożone między wiele instytucji
opracowywana wspólna polityka instalacji i importów danych
utrzymywanie struktur baz nowe funkcjonalności
Na końcu rozdziału przedstaw iono w ykaz program ów FLOSS w ykorzystyw a nych w trakcie akadem ickiego kształcenia bibliotekarzy w INIB UJ.