Avoimen lähdekoodin julkaisujärjestelmien vahvuudet ja heikkoudet
Otathan huomioon, että tämä artikkeli on yli 14 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Verkkopalveluiden alustat Suomessa - markkina alkaa kypsyä.
Vierityspalkin julkaisujärjestelmän valinta -artikkelisarjassa esitellään Suomessa markkinoilla olevia julkaisujärjestelmiä, analysoidaan markkinaa ja käsitellään erilaisia tapoja rakentaa verkkopalveluita.
Avoimen lähdekoodin julkaisujärjestelmät ovat olleet jo useita vuosia merkittävä tekijä julkaisujärjestelmien markkinakentällä. Parina viime vuotena avoimen koodin järjestelmät ovat nousseet haastamaan myös isompia kaupallisia tuotteita.
Tässä artikkelissa käsitellään avoimen lähdekoodin julkaisujärjestelmien vahvuuksia ja heikkouksia verrattuna kaupallisiin, suljetun koodin tuotteisiin. Artikkelin näkökulmana on ensisijaisesti asiakasorganisaatioiden näkökulma, ja esimerkiksi ohjelmistokehittäjien näkökulmaa ei ole tietoisesti korostettu.
Edelleen paljon puhetta, mutta vähän toimintaa
Avoin lähdekoodi on ollut erityisen kuuma aihe viime vuosina esimerkiksi valtionhallinnossa ja monia isoja julkaisujärjestelmä– ja portaalihankkeita onkin lähes pakotettu avoimen lähdekoodin alustoilla toteutettavaksi. Myös monet yhdistykset ja ei-kaupalliset organisaatiot ovat vaatineet avoimen lähdekoodin tuotteita omien verkkopalveluidensa alustaksi.
Suomessa on nyt tuhansia avoimen lähdekoodin julkaisujärjestelmillä tehtyjä verkkopalveluita, mutta valitettavasti mistään vallankumouksesta ei silti voi puhua. Monet isot organisaatiot ovat esimerkiksi pilotoineet avoimen lähdekoodin järjestelmiä, mutta varsinaiset isot käyttöönotot ovat edelleen menneet usein Microsoftin, Oraclen tai IBM:n alustoille. Esimerkiksi Helsingin yliopisto valitsi hiljattain Oraclen portaali- ja sisällönhallintatuotteet verkkopalveluidensa tulevaisuuden alustaksi*.
Asiakkaiden ymmärrys on kuitenkin viime vuosina kasvanut. Esimerkiksi hankkeiden esiselvitysvaiheissa asiakkaat vaikuttaisivat tutustuvan nykyisin laajempaan joukkoon erilaisia tuotteita, toimijoita ja hinnoittelumalleja. Aivan vielä nämä tutkimukset eivät kuitenkaan ole johtaneet toisenlaisiin investointipäätöksiin – ainakaan laajamittaisesti.
Avoimen lähdekoodin tuotteet ovat tehneet kaupallisistakin toimijoista avoimempia
Ehkä merkittävin vaikutus avoimen lähdekoodin tuotteilla on ollut suljetun lähdekoodin tuotteiden kehitykseen ja liiketoimintamalleihin. Lisääntynyttä avoimuutta voidaan pitää myös erittäin merkittävänä muutoksena – vaikka avoimuudella ei koodin avoimuuteen aina viitatakaan. Esimerkiksi Microsoftin SharePointtia on sanottu avoimemmaksi tuotteeksi kuin monia avoimen lähdekoodin tuotteita. Tällä viitataan erityisesti valtavaan yhteisöön, yhteisön tuottamiin laajennuksiin (esim. Codeplex*) ja ylipäätään järjestelmän tarjoamiin laajennusmahdollisuuksiin. Myös Oracle on panostanut viime vuosina valtavasti erilaisten kehittäjäyhteisöjen luomiseen ja avannut omaa dokumentaatiotaan, sisäistä keskusteluaan ja tuotteiden taustalla olevaa suunnittelua. Tämä kaikki on tehokkaasti madaltanut avoimen lähdekoodin ja suljetun lähdekoodin välistä raja-aitaa. Enää ei voi puhua ’kahdesta maailmasta’ vaikka tapa laskuttaa asiakkaita onkin kovin erilainen.
Hyvä valintaprosessi arvioi niin suljetun koodin kuin avoimen koodin tuotteita
Julkaisujärjestelmien kentällä raja-aidat ovat hämärtyneet viime vuosina huomattavasti, mutta mistään avoimen lähdekoodin ja suljettujen tuotteiden sulautumisesta ei voi kuitenkaan vielä puhua. Täten avoimen lähdekoodin järjestelmien markkinakenttää on mahdollista tarkastella omana sektorinaan. Järjestelmävalintoja ei kuitenkaan tulisi tehdä rajoittaen tarkastelua vain avoimen lähdekoodin tuotteisiin, tai pelkästään suljetun koodin tuotteisiin.
Seuraavaksi on tunnistettu joukko avoimen lähdekoodin julkaisujärjestelmien vahvuuksia ja heikkouksia. Katsauksessa on ollut tavoitteena vastata kysymykseen: Mikä erottelee avoimen lähdekoodin julkaisujärjestelmät kaupallisista tuotteista? Milloin kannattaa harkita avoimen lähdekoodin tuotteita? Markkinatilannetta on katsottu erityisesti Suomen julkaisujärjestelmämarkkinoiden näkökulmasta.
Avoimen lähdekoodin julkaisujärjestelmien vahvuudet
- Järjestelmätoimittajan vaihtaminen on helpompaa ja eri yhteistyökumppanit voivat tehdä helpommin yhteistyötä. Asiakkaan näkökulmasta tämä vähentää koettua riippuvuussuhdetta järjestelmätoimittajaan. Esimerkiksi koodin omistajuudesta ei yleensä tarvitse kiistellä.
- Työvoimaa löytyy runsaasti ja uusia tekijöitä voi kouluttaa helposti. Avoimen lähdekoodin järjestelmän voi opetella lähes kuka tahansa ohjelmointitaitoinen, koska järjestelmä on vapaasti saatavilla ja käytettävissä. Matalamman tutustumiskynnyksen myötä myös työvoimaa voi löytyä helpommin järjestelmän kehittämiseen ja ylläpitoon. Monille avoimen lähdekoodin julkaisujärjestelmille löytyy esimerkiksi Suomessa paljon osaamista pienistä it-yrityksistä ja digitoimistoista. Käytännössä myös isoilta toimijoilta löytyy paljon eri järjestelmien osaajia vaikka tuotteita ei virallisessa tarjonnassa olisikaan.
- Lisäosia ja laajennuksia voi ladata verkosta tuhansittain. Jos järjestelmän ympärillä oleva ekosysteemi on aktiivinen ja laaja, on verkko pullollaan valmiita lisäosia ja parannuksia. Ekosysteemin merkitystä lisää näiden laajennuksien lisenssimaksuttomuus, tai hyvin nimelliset kertakorvaukset. Paljon ominaisuuksia kaipaava asiakas voi saada uusia toiminnallisuuksia erittäin kustannustehokkaasti. Tämä voi olla houkuttelevaa esimerkiksi mediatalojen verkkopalveluiden kehityksestä vastaavien henkilöiden näkökulmasta.
- Ei lisenssikustannuksia. Lisenssikustannuksien puuttuminen kiinnostaa erityisesti silloin, jos järjestelmän elinkaaren arvioidaan olevan pitkä. Tästä syystä avoimen lähdekoodin järjestelmät ovat suosittuja alustajärjestelminä ja ei-kaupallisten organisaatioiden piirissä. Aktiivisessa käytössä olevien tietojärjestelmien kohdalla lisenssikulut näyttelevät varsin pientä siivua kokonaisuudesta, mutta mitä passiivisemmassa käytössä ja mitä pidempään järjestelmää käytetään, niin sitä kiinnostavammaksi lisenssikustannuksien puuttuminen yleensä tulee.
Avoimen lähdekoodin julkaisujärjestelmien heikkoudet
- Ei virallista tukea ja tukipalveluiden saatavuus hyvin vaihteleva. Avoimen lähdekoodin järjestelmillä ei yleensä ole virallista tukitahoa joka sitoutuisi korvaamaan vahinkoja vakavissa ongelmatilanteissa ja tarjoamaan tukea järjestelmälle useiden vuosien ajan. Muutaman järjestelmän kohdalla tämä on muuttumassa, mutta ison organisaation kannalta pientä kalifornialaista (tai norjalaista) nyrkkipajaa ei vielä pitkään aikaan voi verrata esimerkiksi Microsoftiin tai Oracleen. Tämä rajoittaa erityisesti isojen organisaatioiden kykyä ja halua hyödyntää avoimen lähdekoodin järjestelmiä. Myös pienemmät tukiongelmat voivat osoittautua ennakoitua vaikeammiksi, koska web-julkaisujärjestelmät ovat laajoja ja monimutkaisia järjestelmiä joihin perehtyminen saattaa kestää osaavaltakin ohjelmoijalta useita viikkoja, jopa kuukausia. Vaikka ohjelmoija hallitsisi yhden php-pohjaisen julkaisujärjestelmän tukityöt, niin toisen järjestelmän tukitöiden haltuunotto voi vaatia kuukausien opettelun. Lyhyesti: Hyvien tukipalveluiden saaminen tietojärjestelmälle on aina merkittävä haaste ja avoimen lähdekoodin julkaisujärjestelmien tukitahot eivät ole vielä todistaneet pystyvänsä tarjoamaan tällaisia vuodesta toiseen. Lisäksi järjestelmille saatavaa, uskottavaa tukea on esimerkiksi Suomessa saatavilla kovin vähän ja sirpaleisesti.
- Tuotteen suosio voi nopeasti laskea. Avoimen lähdekoodin julkaisujärjestelmämarkkina on osoittautunut hyvin nopeasti muuttuvaksi kentäksi. Joka vuosi uusia järjestelmiä ajautuu sivuraiteelle ja uusia tulokkaita syntyy taistelemaan asiakkaista. Esimerkiksi tällä hetkellä kovin muodikas Drupal ei ole nauttinut suuren yleisön suosiosta kuin vasta muutaman vuoden. Esimerkiksi viisi vuotta sitten Suomessa yleisimmät avoimen lähdekoodin julkaisujärjestelmät olivat kovin toisenlaisia. Kuka esimerkiksi muistaa vielä Mambon tai php-Nuken? Täten avoimen lähdekoodin hyödyntäjien on tiedostettava se riski, että oma järjestelmä ei ole enää se kaikkein muodikkain ja kiinnostavin järjestelmä parin vuoden kuluttua. Riippuen järjestelmästä tällä voi olla erilaisia seurauksia. Käytännössä on esimerkiksi havaittu, että jos järjestelmän kehitys ajautuu maailmalla sivuraiteelle tai esiin nousee jokin kiinnostavampi järjestelmä, voivat paikalliset yhteistyökumppanit vähentyä dramaattisesti. Esimerkiksi monet suomalaiset it-yritykset ja digitoimistot ovat vaihtaneet tarjoamaansa avoimen lähdekoodin julkaisujärjestelmää lähes vuosittain.
- Kehitys ohjautuu vahvasti suosion mukaan. Avoimen lähdekoodin julkaisujärjestelmien ominaisuuskehitys ohjautuu vahvasti järjestelmää eniten käyttävien tahojen mukaisesti. Käytännössä tämä tarkoittaa tiettyä ydinjoukkoa ohjelmistokehittäjiä joiden edustamien organisaatioiden tarpeet ohjaavat kehitystä. Esimerkiksi Drupal on käytössä monissa verkkopalveluissa joissa käyttäjien osallistuminen on tärkeässä roolissa. Tämä ohjaa vahvasti Drupalin ydinkehitystä ja lisäosien kehitystä. Jos oma käyttö eroaa kovasti valtavirrasta, ei järjestelmän ekosysteemistä ja jatkokehityksestä välttämättä ole kovin paljon hyötyä. Myös muiden organisaatioiden tarpeisiin tehtyjen laajennuksien täydellinen soveltuvuus omalle organisaatiolle on yhtälö joka hyvin toimii harvoin. Moni avoimen lähdekoodin käyttäjäorganisaatio on siksi päätynyt räätälöimään järjestelmää ja teetättämään omat laajennuksensa. Tällöin organisaatio voi ajautua hyvin nopeasti tilanteeseen jossa käytössä on raskaasti räätälöity julkaisujärjestelmä eikä esimerkiksi päivitettävyys uusiin versioihin ole käytännössä mahdollista.
- Ylläpitokustannukset voivat yllättää. Moni lisenssimaksuttomuudesta huumaantunut asiakas on joutunut toteamaan, että avoimen lähdekoodin julkaisujärjestelmän ylläpito voi osoittautua varsin kalliiksi. Monet avoimen lähdekoodin julkaisujärjestelmätuotteet ovat esimerkiksi osoittautuneet varsin haavoittuviksi ja tällöin tietohallinto voi havaita joutuvansa ajamaan tietoturvapäivityksiä järjestelmään kuukausittain. Jos järjestelmää on vielä räätälöity, niin isompien päivityksien yhteydessä joudutaan haalimaan erikoisosaajia paikalle ja tämä voi vuosien mittaan osoittautua varsin kalliiksi. Myös verkon yleinen kehitys on niin nopeata, että erilaisia ylläpitotoimenpiteitä joudutaan tekemään useimmille järjestelmille jatkuvasti. Julkaisujärjestelmät eivät ole hitaasti kehittyvä alue ja paine uusille toiminnoille ja pienille parannuksille on jatkuva. Tällöin joudutaan maksamaan jatkuvasti useiden tuhansien eurojen laskuja pienistäkin korjauksista ja parannuksista.
Voisikin sanoa, että moni hyöty on kaksiteräinen miekka ja riippuu täysin omasta organisaatiosta ja sovelluskohteesta, että onko asia omalta kannalta hyöty vai heikkous. Esimerkiksi jos organisaatiolla on vahva ja itsenäinen it-osasto, niin ulkopuoliset tukipalvelut eivät ole lainkaan tärkeitä. Toiselle tukipalveluiden saatavuus ja tasokkuus on taas elinehto. Samoin laaja ekosysteemi valmiita lisäosia on joillekin taivas, ja toisille aivan merkityksetön asia.
Avoimen lähdekoodin julkaisujärjestelmiä valitaan usein omituisin perustein
Enää ei avoimen lähdekoodin julkaisujärjestelmätuotteen valintaa voi sanoa poikkeuksellisen rohkeaksi tai omaperäiseksi valinnaksi. On aivan selvää, että monissa tapauksissa voi olla hyvin perusteltua päätyä avoimen koodin tuotteeseen. Sitävastoin valintojen perusteluissa on edelleen usein ihmeteltävää.
On valitettavan yleistä lukea lehdistötiedotteesta asiakkaan lausunto jossa perustellaan avoimen lähdekoodin julkaisujärjestelmätuotteen valintaa pelkästään kustannussyistä. Tämä antaa aivan liian yksiulotteisen kuvan avoimen lähdekoodin järjestelmistä ja myös ostajan ammattitaidosta.
Esimerkiksi kokeneet tietohallintojohtajat eivät yleensä kiinnitä lisenssikustannuksiin edes kovin paljon huomiota, koska tyypillisesti uuden tietojärjestelmän käyttöönottoprojektin kokonaiskustannuksista lisenssikulut ovat vain 10-20 prosenttia. Verkkopalveluprojektien kohdalla julkaisujärjestelmän lisenssikulut voivat olla vain muutamia prosentteja kokonaisprojektista kun kokonaisprojektiin huomioidaan kaikkien yhteistyökumppaneiden kulut ja oman henkilökunnan projektityöpanos. Yleisesti ottaen paljon suurempia kuluja on havaittu syntyvän käyttötarkoitukseen huonosti soveltuvan julkaisujärjestelmän valinnasta joka on johtanut korkeisiin räätälöinti-, koulutus- ja ylläpitokustannuksiin.
Valitettavan usein törmää myös isoihin järjestelmähankkeisiin joissa merkittävä järjestelmävalinta on tehty ainoastaan asiastaan innostuneen yksittäisen ohjelmistokehittäjän suosituksen perusteella. Avoimen lähdekoodin kannalta myöskään tällainen koko valinta- ja arviointiprosessin ohittaminen ei ole omiaan kasvattamaan markkina-alueen uskottavuutta.
Onnistunut valinta perustuu omien tarpeiden ymmärtämiseen
Uutta tietojärjestelmää valitessa tulisi aina pyrkiä löytämään sopivin järjestelmä tehtävään. Valinnan perusteluissa tämä sopivuus tehtävään olisi myös syytä kuvata tarkasti.
Julkaisujärjestelmän valitseminen avoimen lähdekoodin tuotteista vaatii hyvää ymmärrystä siitä mitä omalta verkkopalvelultaan edellyttää ja kuinka sitä aikoo tulevaisuudessa kehittää. Tällöin on mahdollista tehdä hyvä tuotevalinta ja löytää omiin tarpeisiin soveltuva toimittaja toteuttamaan palvelut. Avoimen lähdekoodin julkaisujärjestelmien vahvuudet tulevat esiin esimerkiksi silloin kun ei haluta sitoutua yhteen toimittajaan ja omat tarpeet verkkopalveluille ovat kovin yleisiä ja maltillisia.
Esimerkki 1: Blogisivusto
- Esimerkiksi blogin pystyttäminen on usein projekti jossa avoimen lähdekoodin tuotteet ovat vahvoilla. Blogisivustoon liittyy harvoin erityisvaatimuksia ja maailmalta löytyy paljon lisäosia ja laajennuksia jotka kelpaavat käyttöön sellaisinaan. Haasteena on löytää sopiva kumppani jonka kanssa blogisivustoa voisi kehittää hallitusti eteenpäin.
Esimerkki 2: Perinteinen, viestinnällinen verkkosivusto
- Myös monet yhdistykset ja järjestöt ovat havainneet, että omat vaatimukset verkkopalveluita kohtaan ovat kovin yleisiä ja sisällöntuotannon voluumitkin ovat varsin maltillisia. Todennäköisesti verkkopalveluihin ei myöskään ole varaa investoida vuosittain merkittävästi. Tällöin avoimen lähdekoodin tuote voi tarjota hyvän alustan palveluille mahdollistaen myös pienet, asiakaskohtaiset lisäominaisuudet.
Esimerkki 3: Palvelukanava jossa paljon räätälöityjä toimintoja
- Valtionhallinnossa on kiinnostuttu avoimen lähdekoodin portaali- ja julkaisujärjestelmätuotteista myös hankkeissa joiden elinkaari tulee olemaan pitkä ja odotettavissa on runsaasti räätälöitäviä ominaisuuksia ja integraatioita eri tietojärjestelmiin. Tällöin on asiakkaan kannalta tärkeätä saada koodin omistajuuskysymykset selviksi ja mahdollisuus vaihtaa toimittajaa vaikka kesken projektin. Avoin lähdekoodi ei ratkaise näitä ongelmia, mutta helpottaa jonkin verran neuvotteluja.
Yhteenveto: avoimen lähdekoodin julkaisujärjestelmät lähestyvät murrosikää
Avoimesta lähdekoodista on tullut parin viime vuoden aikana kabinettikelpoinen vaihtoehto suljetuille, kaupallisille julkaisujärjestelmätuotteille. Keskeisin haaste on tosin edelleen tiedon puute ja turha vastakkainasettelu eri osapuolien välillä. Avoimen lähdekoodin tuotteet eivät ole hopealuoteja ongelmiin ja suljettujen tuotteiden markkina-asema ei ole radikaalisti uhattuna.
Ala on kehittynyt Suomessa nopeasti. Monen järjestelmän osaamista löytyy jo useilta kymmeniltä eri toimittajilta. Myös tukipalveluiden kehitys menee koko ajan parempaan suuntaan. Toistaiseksi markkina on kuitenkin edelleen hyvin nopealiikkeinen ja järjestelmiä valitaan hieman omituisin perustein.
Parhaiten avoimen lähdekoodin tuotelupaukset tuntuvat toimivan tilanteissa joissa vaatimukset verkkopalveluita kohtaan ovat yleisiä ja maltillisia. Heikoiten avoimen lähdekoodin tuotteet tuntuvat toimivan silloin kun verkkopalvelut ovat erittäin bisneskriittisiä ja tuotteen käytettävyys, tuotteelle saatavat tukipalvelut ja integraatio-ominaisuudet ovat tärkeitä valintaperusteita. Lisäksi monia tuotteita käytetään erittäin räätälöityjen palvelukanavien alustoina, jota voidaan pitää eräänlaisena tietoisena tuotteiden väärinkäyttönä. Räätälöintialustoiksi kun ei julkaisujärjestelmätuotteita ole yleensä tarkoitettu.
PS. Seuraavassa artikkelissa on tarkoitus mennä pintaa syvemmälle ja ottaa tarkasteluun tärkeimmät avoimen lähdekoodin julkaisujärjestelmätuotteet Suomessa. Käsittelyssä tulevat olemaan muun muassa Drupal, Joomla*, WordPress, eZ Publish*, LifeRay, Alfresco, DotNetNuke, Plone ja Umbraco. Toivottavasti katsauksien kautta saadaan enemmän tietoa, keskustelua ja lopulta ymmärrystä alalle avoimen lähdekoodin julkaisujärjestelmätuotteista.
Kirjoittaja työskentelee sisällönhallintajärjestelmien konsulttina Sinisessä Meteoriitissa. Sininen Meteoriitti toteuttaa verkkopalveluita Microsoft-teknologioilla, esimerkiksi SharePointilla. Esitetyt näkemykset ovat kirjoittajan omia.
(*toim. huom. Linkkejä poistettu toimimattomina.)
PS. Aina ajantasaisen katsauksen julkaisujärjestelmien markkinaan löydät North Patrolin sivustolta: Julkaisujärjestelmät ja verkkokauppajärjestelmät -hakemisto
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
28 kommenttia on “Avoimen lähdekoodin julkaisujärjestelmien vahvuudet ja heikkoudet”
Kommentointi on suljettu.
Kari Maikkola
Tietoturvaseikat ja eroavaisuudet jäivät tässä artikkelissa kokonaan käsittelemättä.
Lisäksi jos puhutaan asiakasorganisaation näkökulmasta, olisi hyvä tuoda esille monien tuotteistettujen, suljetun koodin ratkaisujen keskeinen suunnittelunäkökulma eli nimenomaan asiakkaat (loppukäyttäjät). OS- ratkaisuilla näkökulma on usein kehittäjän, ja tuotteita tai tuotemoduuleita kutsutaankin rehellisesti projekteiksi.
Edelleen kyseenalaistaisin tuon toimittajariippumattomuuden pelkästään positiivisena asiana. Kyllä usein tilaajan kannalta on positiivista se, että kehitystyössä, tukipalveluissa ja erityisesti kriittisen tilanteen sattuessa on selkeä, olemassa ja saatavilla oleva taho, jonka kanssa asiaa voi alkaa selvittämään. Tämä negatiivinen näkökulma saattaa johtua ehkä joissakin julkishallinnon tapauksissa esiintyneistä tilaaja-toimittajaongelmista, jotka liittyvät hallitsevaan markkina-asemaan tietyissä tuotteissa/toimialaratkaisuissa.
Toki perussaitteihin ja muuten perusteltavissa oleviin tapauksiin avoimen lähdekoodin ratkaisut ovat hyvä vaihtoehto.
Tuo avoimen lähdekoodin ratkaisujen muodikkuus on tietysti huono puoli ja tilaajan näkökulmasta lisäksi erittäin vaikeasti ennakoitavissa oleva asia. ”Oikea” valintahan ei ole kenenkään käsissä.
Petri Mertanen
Minkä pohjalta Perttu perustelisit, että isot organisaatiot eivät olisi ottaneet avoimen lähdekoodin sisällönhallintajärjestelmiä käyttöön? Esimerkiksi Naviatechin asiakkuudet ovat tulleet pääsääntöisesti tältä sektorilta ja siltä osin meidän oma kokemus on pahasti ristiriidassa tuon esitetyn kanssa. Olen samaa mieltä, että asiakkaiden ymmärrys on kasvanut ja itse uskon, että suurempi muutos on vasta tulossa.
Muutenkaan asia ei ole mielestäni aivan mustavalkoinen. Kun valitsimme reilu pari vuotta sitten eZ Publishin pääsääntöiseksi sisällönhallintajärjestelmämksi, oli valintakriteerinä nimenomaan kaupallisen yhtiön koordinoima järjestelmän tuotekehitys ja tukipalvelut.
Olen samaa mieltä, että sisällönhallintajärjestelmä pitäisi valita tiettyjen tarpeiden ja kriteerien mukaan – riippumatta siitä onko se suljettua vai avointa lähdekoodia. Hyvin suoritetun, ja ennenkaikkea ennakkoluulottoman, valintaprosessin avulla varmasti siinä myös onnistutaan. Jään odottamaan mielenkiinnolla syvempää analysointia eri järjestelmistä.
Sillä välin avoimien sisällönhallintajärjestelmien vertailussa voi auttaa seuraava: cms-software-review.toptenreviews.com/
Ja tervetuloa kaikille Internet Expoon juttelemaan lisää aiheesta ja tapaamaan myös eZ Systemsin asiantuntijoita!
Perttu Tolvanen
Kiitos loistavista kommenteista.
Kari: Punnitsin pitkään, että nostanko esiin tuon käytettävyysnäkökulman. Jätin sen lopulta pois, koska avoimen lähdekoodin tuotteissa on myös erittäin hyvän käytettävyyden tuotteita ja tuota kehittäjälähtöisyyttä ei enää voi mielestäni luokitella vain heikoksi käytettävyydeksi. Kehittäjälähtöisyys ilmenee monessa järjestelmässä, mutta välttämättä tavallisen sisällöntuottajan kannalta järjestelmä ei ole käyttöliittymältään aivan karmea. Tosin tämä perustuu vertailuun muihin markkinan tuotteisiin ja karu tosiasia on, että suljetun koodin tuotteissa on ihan yhtä karmeita käyttöliittymiä kuin avoimenkin koodin tuotteissa. Täten tässä kohtaa en näe olevan koko markkinaa erottelevaa piirrettä.
Pikemminkin näen heikon käytettävyyden olevan koko alan yhteinen haaste joka koskettaa niin suljettuja kuin avoimia tuotteita. Ominaisuustaulukoiden kautta on vain yksinkertaisesti valittu tuotteita liian pitkään!
Kari: Olen samaa mieltä, että monelle asiakkaalle tiivis toimittajasuhde on paljon tärkeämpää kuin toimittajariippumattomuus. Joillekin asia on kuitenkin hyvin tärkeä, ja tämä asia kyllä erottelee suljetut tuotteet avoimista tuotteista vahvasti. Sen tärkeys on tosiaan hyvä keskustelunaihe, koska avoimen koodin edustajat käyttävät toimittajariippumattomuutta lyömäaseena vähän turhan helposti. Täten ymmärrän hyvin pointtisi.
Petri: Jo juttua kirjoittaessani tiesin, että olisit ensimmäisiä kommentoijia! :) Ja tosiaan mitään yksiselitteistä tutkimusta ei aiheesta ole esittää. Gradussani tosin olen viitannut hieman vanhempiin tutkimuksiin joissa nimenomaan sinun esittämääsi kantaa puolletaan – eli nimenomaan isot yritykset ovat kiinnostuneet avoimen lähdekoodin järjestelmistä (myös potentiaaliset säästöt ja hyödyt kun ovat isoimmat isoilla firmoilla). Suomessa kuitenkaan isot firmat (tuhansia henkiä) eivät ole varsinaisesti kaduilla ryntäilleet metsästämässä tuoreimpia avoimen lähdekoodin julkaisujärjestelmiä. Monet keskisuuret ja suuret organisaatiot ovat sitävastoin rynnänneet SharePoint-junaan ja moni on ryntäilyssään myös unohtanut kokonaan vertailla sopivia vaihtoehtoja. Kirjoittamani kanta perustuu siis ensisijaisesti siihen, että avoimen lähdekoodin julkaisujärjestelmien vahvasta tarjonnasta huolimatta minkäänlaista vallankumousta ei ole ilmassa. Itsekin uskon, että suurempi muutos on vasta tulossa.
Sinun edustamasi eZ Publish tosin edustaa kieltämättä mielenkiintoista hybridiratkaisua jonka uskon madaltavan monen organisaation tietä kohti avoimen koodin hyödyntämistä – ja muutenkin avoimempaa suhtautumista tietojärjestelmätuotteiden ja teknologioiden valintaan.
Mitä tulee viittaamaasi linkkivinkkiin, niin sanoisin kuitenkin, että luen mieluummin pohditun artikkelin eZ Publishin soveltuvuudesta eri käyttöskenaarioihin kuin ominaisuusmatrixin joiden tuijottelulla on hyvin vähän tekemistä onnistuneiden järjestelmävalintojen kanssa. Löytyisikö sinulta hyvää linkkivinkkiä tällaiseen artikkeliin? :)
Antti Peisa
Erinomainen kirjoitus, kiitoksia! Odotan innolla jatkoa ja etenkin Alfrescosta lisätietoja.
Miten Perttu näet Google Appsien kaltaiset ”pilvipalvelut” tässä valossa? Esim. Alfrescon ja Sharepointin kanssahan ollaan hyvinkin pitkälti samoilla apajilla…?
Petri Mertanen
Omat kokemukseni sivustopalvelusta (http://sites.google.com) ovat olleet varsin positiiviset. Ne integroituvat näppärästi muiden Googlen tarjoamien työkalujen (kalenteri, kuvat, videot, Google Analytics, Webmaster Tools) kanssa. Erittäin kustannustehokas ratkaisu (alk. 10 €/vuosi = domainin hinta) ja soveltuu oikein hyvin pienille sekä mikroluokan yrityksille.
Nyt kun Alfresco on mainittu, niin sisällönhallintajärjestelmät voidaan erotella eri kategorioihin, esim. WCM (web content management) ja DM (document management) tyyppisiin järjestelmiin. Nämä eri kategorian järjestelmät soveltuvat hieman eri tehtäviin ja eivät välttämättä kilpaile keskenään. Järjestelmäintegrointia ajatellen on olemassa ehdotus uudeksi standardiksi nimeltä CMIS ja oikeita toteutuksiakin tehty.
http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Kari Maikkola
Huomiosi Perttu ovat oikeita. Asiathan eivät useinkaan ole aivan mustavalkoisia. Taannoin osallistuin koulutukseen, jossa käytiin läpi avoimen lähdekoodin ohjelmistojen käyttöä kaupallisessa liiketoiminnassa. Siinäkin tilaisuudessa käytiin jonkun verran keskustelua OS-tuotteista suhteessa suljetun lähdekoodin tuotteisiin. Vähän liian usein lähtöasetelma vain on tyyliä: ”OS hyvä, muut pahoja”. Näkisin, että etenkin julkishallinnossa monessa kohtaa on kuitenkin hyvä asia, että alustaksi valitaan joku Open Source-ratkaisu. Tämä ainakin teoriassa mahdollistaa laajan potentiaalisen kehittäjäjoukon.
Käyttöliittymän toteutus on melkoisen haastavaa. Tai ainakin järeämmissä tuotteissa, joissa ominaisuuksia alkaa olla todella mittavasti. Silloin tällöin myyntipalavereissa vastapuoli toivoo yhtä helppoa käytettävyyttä kuin nykyisin käytössään olevalta tuotteelta, johon kuitenkin kaipaavat lisää toiminnallisuuksia. On tietysti helppo tehdä käyttis tarpeisiin, jotka ovat hyvin pelkistetyt. Kylläpä tuota itsekin aina on hieman ihmeissään, kun tulee uusia MS Office-versioita ja yrittää löytää sieltä ne tutut toiminnot – ja edelleen ne sadat toiminnot wordissa ja excelissä saavat olla ihan rauhassa:)
Juha Söderholm
Yksi mihin tässä ei oteta juurikaan kantaa on järjestelmän muokkausmahdollisuudet. Esimerkiksi SEO-projekteissa usein tulee vastaan järjestelmiä (Yleensä Microsoft-pohjaisia) joiden 100% tai edes lähes hakukoneystävälliseksi tekeminen on hyvin hankalaa ainakin useimpien järjestelmän toimittaneiden tahojen mielestä (Yleensä mahdotonta).
Olen työskennellyt paljon Microsoftin, Oraclen, Lotuksen sekä IBM:n järjestelmien kanssa ja pidän niitä hyvin paljon enemmän intranettiin sopivimpina kun julkiseen nettiin – nimenomaan niiden kiviaikaisen muokattavuuden takia.
Tämä siitä syystä, että nykyään perusedellytys CMS-järjestelmälle alkaa olemaan hakukoneystävällisyys ja lähes jokainen järjestelmätoimittaja tuntuu kertovan että se oma CMS-järjestelmä on ”hakukoneystävällinen” tai ”hakukoneoptimoitu”. Useimmiten on joutunut toteemaan, että joko a) asiakas on viilattu linssiin tai b) CMS-järjestelmän toimittaja ei edes tiedä mitä on hakukoneystävällisyys.
Sami Kallioinen
Hakukoneoptimointi oli hyvä huomio. Itse olen optimoinnissa törmännyt siihen, että urlista oli mahdotonta tehdä selkokielistä. Tämä vaikeuttaa myös GA:n virittämistä. Toki tähän olemme saaneet muuta apua.
Petri Mertanen
Erittäin hyvä huomio Juhalta ja Samilta. Pahimmillaan olen nähnyt, että järjestelmätoimittajat ovat väittäneet, että sivustot ovat valmiiksi optimoituja. Lähes poikkeuksetta hakukoneoptimointi vaatii kuitenkin aina työtä. Mikäli kysymyksessä on laaja sivusto ja sisällönhallintajärjestelmä ei tee siistejä ja selkokielisiä URL-osoitteita niin kyllähän se vie tehoa Google Analyticsin ja muiden seurantajärjestelmien hyödyntämisestä.
URL-osoitteita tärkeämpänä asiana pidän sivujen otsikoiden (page title) vapaata muokattavuutta. Tässä vielä lisää huomioitavaa sisällönhallintajärjestelmien ostajille SEO näkökulmasta:
– vapaasti muokattavat sivujen otsikot (titlet)
– vapaasti muokattavat sivujen meta-tagit (page description)
– selkokieliset ja siistit URL-osoitteet
– tekstimuotoinen tai päivitettävä (hakukoneelle näkyvä) navigaatio
– automaattisesti muodostettava sivukartta (ja sitemap.xml)
– aiheiden tai yksittäisten sivujen tagit ja ns. tagi-pilvi
– tekstiotsikot html-koodien sisällä (h-tagit)
– avainsanojen muotoilut (lihavointi) ja sivuston sisäinen linkitys (sekä rikkinäisten linkkien tarkistaminen)
– kuvien alkuperäiset tiedostonimet, vaihtoehtoiset tekstit (alt txt) ja otsikot (title)
Juha Söderholm
Yleisin ongelma on järjestelmän teettämät tuplasisällöt & ongelmat selkokielisien urlien kanssa & navigaation vakaa muokkaaminen attribuuteilla.
Juha Söderholm
Vakaa == Vapaa.
Jani Tarvainen
Puutteistaan ja omituisuuksistaan huolimatta kannalta eZ Publish on kohtuullisen hyvä systeemi hakukoneoptimoinnin kannalta.
– HTML:n title-kenttää varten voi tarvittaessa luoda oman kentän sisältöluokkaan
– Osoitteet ovat selkokielisiä (vaikka oletustranslitterointi onkin skandien kanssa ns. hanurista, öljysäiliö -> oeljysaeilioe)
– Perussisällön tuplaindeksoinnin estävä canonical-tagia käyttävä laajennuksen luominen oli triviaalia: *linkki poistettu toimimattomana*
– Järjestelmä pitää sisäisesti historiaa sivujen vanhoista sijainneista, eli jos sivu siirretään rakenteessa paikasta toiseen niin myös vanhat osoitteet toimivat (301 redirect)
Lisäksi tarjolla on useita sitemaps-laajennuksia joista osa jopa toimii.
Jani Tarvainen
Ja kiitos vielä Pertulle mielenkiintoisesta artikkelista. Ja tulevista jutuista odotan erityisesti näkemyksiä Microsoft-teknologialla luodusta Umbracosta :)
Mikko Hämäläinen
Yksi kulma sisällönhallintaan on mielestäni se, että usein CMS-järjestelmät (mitä termillä nyt sitten eri yhteydessä tarkoitetaankaan) ovat käytännössä kasvaneet omiksi frameworkeiksi. Tämä ei välttämättä ole huono asia, mutta usein tuo mukanaan kummallisuuksia ja joissain tapauksissa periaatteessa helpot asiat vaativat turhaa työtä.
Tästä näkövinkkelistä suosittelisin tutustumaan frameworkkeihin joissa on sisällönhallintamaisia piirteitä. Yksi vahva tällä alueella on Django, jolla sisällönhallinnan toteutus on lapsellisen helppoa, mutta alla on kuitenkin geneerinen framework jolloin ei-sisällönhallinnollisten asioiden tekeminen on helppoa kun CMS ei ole tiellä. Eli CMS ei ole tässä tapauksessa intrusiivinen. Oman kokemuksen mukaan tässä on kyllä edessä melkoinen pois-oppimisprosessi kun omalla kontolla on n+1 CMS-implementointia ja ajattelu on ollut hyvin CMS-lähtöinen.
Helpoimmalla (arkkitehtuurimielessä) tietenkin pääsee kun erottaa content repositoryn ja sisällönhallinnan prosessit täysin saiteista, mutta tämä ei useinkaan ole edes keskisuurissa projekteissa relevantti vaihtoehto, ellei organisaatiossa ole valmiiksi välineitä olemassa.
Jani Tarvainen
Vaikka homma uhkaa nyt lähteä lapasesta niin jatkanpa vielä hieman Content Repositoryistä ja eZ Publishista (lähinnä sen takia että sen parissa on eniten tullut viimeaikoina puuhasteltua).
Eli eZ Systems on rakentanut Solr integraatiota (nimellä eZ Find). Kaikenkaikkiaan tämä toimii nyt jo erittäin hyvin, mutta jatkossa on mahdollista käyttää Solria eräänlaisena Content Repositorynä niin että julkisen sivuston sisältö voidaan hakea kokonaisuudessaan Solrista. Eli hallintakäyttöliittymällä hallinnoidaan Solrin taksonomiaa.
Solr ei taida oikeastaan olla CR, mutta tämä vaikuttaa ihan mielenkiintoiselta ratkaisulta joka mahdollistaa tulevaisuudessa esim. geospatiaaliset haut sisällöstä mikäli tarvittava metadata on olemassa. Lisäksi yllämainitun ratkaisun käyttäminen yleisenä CR:nä on haasteellista, sillä vaikka Solrin taksonomiasta voisi lukea dataa niin päivitys pitäisi hoitaa eZ:n APIlla jotta Solr ja eZ Publishin tietokanta pysyvät ajantasalla. Lisäksi Solrissa ei käsittääkseni ole versiointia ja oikeuksienhallintakin taitaa puuttua täysin. Voin toki olla väärässä.
Mikko: Mikä olisi mielestäsi hyvä käytännön vaihtoehto Content Repositoryksi LAMP-maailmaan? Olen itse leikitellyt ajatuksella CR:ää käyttävästä mainstream avoimen lähdekoodin CMS:stä, mutta en ole löytänyt moista. Mielestäni ”nyt vaan on tyhmää” että jokainen CMS projekti rakentaa uudelleen SQL-kantaa sisällön ja navigaatiorakenteiden tallentamiseen.
Jos palataan vielä alkuperäiseen artikkeliin niin ”häviäjiä” tässä pelissa mielestäni ovat kuitenkin pienet talot jotka rakentavat omaa CMS:äänsä. Nämä eivät tarjoa isojen kaupallisten tuotteiden stabiiliutta eivätkä avoimen lähdekoodin kehitysvauhtia. Toki näillekin riittää varmasti bisnestä, joten en manaa nyt tiettyjen talojen kuolemaa. Itse en vain ostajan paikalla valitsisi näitä ilman erityisen hyvää syytä.
Yksi vaihtoehto mistä ei taidettu juuri puhua on että Kotisivukoneen kaltaiset palvelut sopivat myös monelle. Lisäksi Acquia tarjoaa pian hostattua Drupalia Drupal Gardens nimen alla: *linkki poistettu toimimattomana*
Mikko Hämäläinen
Jani, esittämäsi SoLR on monessa suhteessa erittäin hyvä vaihtoehto content repositoryn tilalle sisällön jakelupäässä ja tiedän monta tällä tavalla toteutettua isompaa toteutusta Suomessa. Toki siinä on rajoitteensa esimerkiksi dynaamisen metadatan suhteen (tai en nyt ihan viimeisimmillä versioilla ole leikkinyt), mutta nuo voi useimmiten ihan järkevästi kiertää.
Varsinaisista content repositoryista ekana tulee mieleen Alfresco tai Sling/Jackrabbit. Noitahan toki piisaa, mutta kaikesta standardoinnista huolimatta nuo harvemmin puhuvat oikeasti ristiin ilman jonkinlaista säätämistä. En itse asiassa tiedä onko tällaista comboa lainkaan, paitsi ehkä Magnolia jos oikein muistan. Itse olen kuitenkin aikaa sitten luopunut ajatuksesta että olisi olemassa yleispätevää ratkaisua eri tarpeisiin ja erityisesti saittirakenteen ja näkymien hallinta on ehkä isompi ongelma kuin itse sisällön säilöminen jonnekin. Sling esimerkiksi noudattaa pitkälti NoSQL filosofiaa jolloin tietomalli ei ole se pullonkaula ja toteutus on sikäli nopeata – valmis CMS (hallintapuoli) taasen tässä puuttuu joten kahta hyvää ei voi saada.
En nimenomaan rakenteenhallintaan ole täydellisiä (lue: joustavia ja käyttäjälle inhimillisiä) työkaluja löytänyt vaikka olen kolunnut läpi kaikki open source -tuotteet joihin olen törmännyt ja kaupallisista on myös kokemusta. Mutta rehellisesti en usko että sellaisia on myöskään tulossa ihan lähiaikoina, joten räätälöinniksi helposti menee vielä pitkään (ja sitten versiopäivitysten yhteydessä kiroillaan).
Tuotteista lienee paras kuitenkin on se jota itse parhaiten osaa, jolla asiakas saa hinta/laatu suhteessa parhaan toteutuksen omaan tarpeeseensa ja jonka puutteiden kanssa pystyy elämään. Ja jota kyetään pitkässä juoksussa myös tukemaan.
Miikka Salavuo
Hienoa Perttu! Kommentoin nyt erään yliopiston intran valintaprosessissa mukana olleen näkökulmasta ja kommenttini koskevat laajempia järjestelmiä.
1) Kyseisessä yliopistossa oli tehty epäonnistunut intrahankinta, kun hankittiin järjestelmä, jolla oli vain yksi palveluntarjoaja. Tästä syystä haettiin tuotetta, jonka toimittajaa voisi tarvittaessa vaihtaa ja/tai kilpailuttaa.
2) Yksi tärkeä pointti näin sosiaalisen median aikana on integroitavuus – sekä mahdollisuudet että sen kustannukset. Paitsi ”some-sovelluksia”, organisaatiolla saattaa olla käytössä järjestelmiä, jotka pitäisi saada kustannustehokkaasti liitettyä yhteen käyttöliittymä- ja käyttäjähallintatasolla sekä ylläpidon kannalta valittavan intrajärjestelmän kanssa (esimerkkinä vaikka Oodi, Moodle ja hallinnon järjestelmät yliopistoissa). Jos yritys on tehnyt aiemmin integraatioita näihin ja valmis koodi löytyy, on ratkaisu asiakkaan kannalta varmaan edullisempi ja varmempi. On vallalla käsitys, joka osin on tottakin, että OS-järjestelmät ovat avoimempia näihin integraatioihin, joskin tämäkin lienee muuttunut, kun standardit ovat vakiintuneet enemmän ja isot suljetut ovat niitä alkaneet tukea.
3) Imago ja brändi julksisella sektorilla: Huomasin, että suljetun koodin järjestelmiä tarjoavat yritykset toivat esiin isoja asiakkaitaan (globaaleja pörssiyrityksiä) ja loivat ainakin minulle vaikutelmaa, että tää on varmasti todella kallista. Kun taas OS-palveluntarjoajat olivat usein maanläheisempiä imagoltaan ja enemmän kotonaan yliopiston toimintakulttuurissa. Tämä on tietenkin vain vaikutelmaa. Toisaalta suljetut järjestelmät, etenkin MS:n, IBM:n, Oraclen järjestelmät antavat vakuuttavan kuvan itsestään, ehkä suuren kokonsa, suurten asiakkaiden osalta jne. Google taas ei oikein vielä, monelle se on hakukonefirma, joka ”tarjoaa peruskäyttäjille näppäriä apuvälineitä”.
Perttu Tolvanen
Loistavaa keskustelua täällä.
Antti: Palveluna ostettavat ratkaisut ovat oma lukunsa josta on myös tulossa artikkelia, mutta täytyy kyllä sanoa että ne ovat paljon hankalammin asemoitava alue. Niitä ei myöskään voi pitää kovin yhtenäisenä kenttänä, koska palveluehdot ja hinnatkin vaihtelevat todella paljon. Avoimen koodin puolella palveluratkaisut ainakin ovat selkeitä, koska kun rajat tulevat vastaan, niin systeemin voi siirtää omalle palvelimelle. Suljettujen tuotteiden puolella vastaava ei onnistu samalla tavalla – mutta asia ei ole käytännössä ollenkaan näin selkeä. Kiinnostavimpia tällä hetkellä ovat varmasti WordPress.com ja Drupal Gardens. Kaupallisten puolella mm. Moogo, Hammerkit ja Bildy ovat lupaavia kotimaisia tuotteita.
Google Sitesia en oikein pidä saman sarjan pelaajana. Google Appsin Premium Edition on ehkä parin kehitysaskeleen päässä siitä, että se olisi todella vakava pelaaja pienempien firmojen tiedonhallinnan kokonaisratkaisuksi kattaen kaiken sähköpostista ryhmätyöhön ja intranäkymiin. Vakavasti otettava web-julkaisujärjestelmä se ei ole ja tällä hetkellä näyttää että ei myöskään tule olemaan ihan lähitulevaisuudessa. Mutta tiedonhallinnan perusratkaisuksi Googlen kehitys näyttää oikein hyvältä ainakin kun tietää mitä on tulossa kulman takana. Ja hinnalla 40e/käyttäjä/vuosi se pistää monen tietohallintojohtajan miettimään Microsoftin valintaa toisenkin kerran.
Alfrescosta on seuraavassa artikkelissa enemmän juttua. Pidän Alfrescoa vähän vaikeasti luokiteltavana järjestelmänä, jonka keskeisin ongelma on se, että sitä käytetään niin monenlaisiin tarkoituksiin. Täten se itse asiassa vertautuu SharePointtiin parhaiten avoimen lähdekoodin puolelta.
Google Sitesiin verrattuna Alfresco ja SharePoint ovat ihan toista järeysluokkaa ja ihan toisenlaisten organisaatioiden tarpeisiin. Tosin SharePointin palveluna ostettava paketti näyttää ainakin loppuvuodesta tulevan 2010 osalta ihan kiinnostavana kilpailijana. Nykyinen 2007:han on palveluna ostettavana ratkaisuna aika rajattu. Myös 2010 tulee olemaan rajattu, mutta aivan varmasti Suomessakin moni iso organisaatio valitsee SharePointista palvelumallin 2010 version osalta. Täten palvelumalli yleistyy ja sitä kautta SharePoint lähestyy myös Google Sitesiä samalla kun Google paketoi omaa kokonaisuuttaan paremmin. Alfrescolta toivoisi tähän ryhmätyö/dokumenttienhallinta/intranet -skenaarioon kunnon haastetta. Ihan vielä se ei mielestäni sellainen ole.
Petri: Esiin nostamasi CMIS standardi on tosiaan yksi mielenkiintoisimmista uudistuksista tällä kentällä ja sitä kautta ehkä jatkossa eri järjestelmien yhteentoimivuus paranee jonkin verran. Tosin CMIS on vielä kovin yksinkertainen nykyisellään (tai eihän se vielä hyväksytty ole) joten lisää painetta tarvittaisiin.
Juha: Tuosta hakukoneystävällisyydestä voisi tosiaan ottaa ihan oman aiheensa. Joissakin järjestelmissä tietyt listaamasi muutokset ovat tosiaan lähes mahdottomia toteuttaa. Mainitsemasi isot toimittajat ovat olleet varsin hitaita kuuntelemaan web-julkaisun vaatimuksia. Erityisesti Oracle ja IBM ovat pitäneet hyvin pitkään web-julkaisemista aivan toisarvoisena kenttänä ja myyntimiehet ovat sitkeästi väittäneet että heidän käsittämättömät portaaliframeworkkinsa ovat hyviä julkaisujärjestelmiä. Nyt tämä tosin muuttuu hiljakseen, koska kaikki ovat yritysostojen kautta hankkineet myös erittäin moderneja järjestelmiä. Tosin edelleenkin on kyse eniten siitä, että järjestelmiä pystytettäessä konfigurointi tehdään väärin tai jätetään tekemättä näiltä osin. Tällöin esim. url:t tuotetaan jonkun kiinteän mallin mukaan joka on defaulttina ollut paketissa (ja joka pitäisi aina määritellä mutta kun käyttöönottavassa tiimissä ei ole ollut yhtään web-kehittäjää vaan java-koodareita jotka ovat aiemmin koodanneet toiminnanohjausjärjestelmiä). Myös tuplasisältöjen ongelmat voi usein konfiguroinnilla poistaa kun järjestelmää pystyttää. Myös navigaation rakentamisen voi monessa tuotteessa tehdä hyvin monella eri tavalla ja paketissa voi olla useita eri navigaatiokomponentteja. Näistä valitseminen vain tehdään käyttöönotossa väärin kun web-julkaisun erityisvaatimuksia ei ymmärretä. Täten isojen tuotteiden kohdalla sanoisin ongelman olevan enemmän siinä, että niitä osaavassa porukassa/firmoissa on harvoin todellisia web-ammattilaisia.
Mikko: Hyvä kommentti noista frameworkeista. Ne tosiaan ovat tuoneet uuden ulottuvuuden kentälle. Nykyisin onkin yhtä tärkeätä mielestäni päättää, että kannattaako jotain julkaisujärjestelmätuotetta käyttää ollenkaan. Monessa verkkopalvelussa kun julkaisujärjestelmätuotteesta ei saateta edes käyttää monia ominaisuuksia, niin kannattaa tosiaan miettiä olisiko järkevämpää ottaa jokin räätälöintiin tarkoitettu paketti käyttöön. Julkaisujärjestelmien perusongelmahan on tosiaan se, että niitä myydään kovin mielellään juuri räätälöintialustoina vaikka ne usein siihen ovat varsin epäsoveltuvia.
Mitä tulee repositoryjen käyttöön, niin itse olen myös nähnyt aivan liian monta liian kankeata toteutusta jossa rakenteenhallinta ja sisällön muokkaus on saatu tehtyä aivan kryptiseksi hommaksi. Usein nämä käyttäjien kannalta erittäin hankalat ja vaikeat toteutukset ovat sitten vielä maksaneet maltaita kun käytössä on hienoimmat lelut mitä rahalla saa. Ja voi tosiaan olla totta, että merkittäviä parannuksia ei tähän ole lähiaikoina tulossa. En kuitenkaan itse katso räätälöintihommien olevan välttämättä se reitti jolle pitäisi ensimmäisenä lähteä. Tietysti jos vaatimuksia ei pystytä taivuttamaan, niin sitten tälle reitille pitää mennä ja rajoittavat tuotteet kannattaa heittää kuuseen silloin. Tämä on kuitenkin valinta joka on syytä tehdä hyvin tietoisesti, koska kummassakin vaihtoehdossa menettää jotain.
Hyviä tuotteita kun on maailmassa varsin paljon ja jos omat vaatimukset vain osuvat tuotteen tarjoamiin ominaisuuksiin, niin pystytys on nopeata ja kustannustehokasta ja käyttö tehokasta. Tämä on lupaus johon avoimen lähdekoodinkin tuotteissa kannattaa pyrkiä. Liian moni lupaa mielestäni helppokäyttöistä tuotetta ja joustavaa räätälöintialustaa edelleenkin – tai vaikka ei lupaisikaan, niin asiakas uskoo sinisilmäisesti saavansa kaksi kaunista samalla kertaa.
Miikka: Kiitos hyvästä kommentista. Avoimen koodin tarjoama parempi toimittajariippumattomuus ja parempi integroitavuus erilaisiin järjestelmiin ovat tosiaan ihan valideja argumentteja. Tosin esimerkiksi SharePoint on hyvä esimerkki Suomessa siitä, että se vastaa näihin kumpaankin vaatimukseen usein paremmin kuin yksikään avoimen koodin järjestelmä. Eli suljettu tuote ja suljettu lähdekoodi eivät suinkaan ole samoja asioita aina. Tosin pitkällä tähtäimellä ero voi olla merkittävä. Täten itsekin toivon CMIS standardin yleistymistä ja eri tuotteiden parempaa yhteentoimivuutta. Näin saataisiin helpommin ympäristöjä joissa avoin koodi ja suljettu koodi elävät sopusoinnussa ja ehkä jopa ilman kallista, jatkuvaa integraatiotyötä.
Projektien hintojen osalta olen jo kuullut itsekin tarjouspyyntökierroksista joissa avoimen lähdekoodin ratkaisulla on saatu aikaiseksi kierroksen korkein hinta. Täten hintakysymys alkaa myös tasapainottua kun harva toimittaja enää pyytää heti alkuun sataa tonnia pelkistä lisensseistä. Tähän kehitykseen vaikuttavat myös palveluna tarjottavat tuotteet jotka viimeistään opettavat asiakkaat laskemaan tuotteen elinkaarihintaa eikä pelkästään hankintahintaa.
Ykä
Kiitos kiinnostavasta kirjoituksesta. Kaksoislisenssimalli jota esim. MySQL tai Life Ray soveltavat jäi tässä osin käsittelemättä. Tuolla mallilla toteutetuissa projekteissa voidaan hyödyntää avoimen ohjelmistokehityksen runsas aluskasvillisuus ja saada asiallinen tuki alustalle. Kommenteissa IBM:n järjestelmiin viitattiin suljettuina. CMS:ien osalta en tunne asiaa kovin hyvin, mutta käsittääkseni talo on aika voimakkaasti mukana myös avoimen koodin kehitystyössä ja OSI:ssä.
Perttu Tolvanen
Simo: Helsingin yliopistohan on jättimäinen organisaatio joka ei varmasti ole täysin yhteen alustaan menossa vaikka haluaisikin – enkä usko että tämä on edes tarkoituksena vaikka Oraclen järjestelmät nyt onkin valittu ensisijaiseksi alustaksi. Valittu Oracle UCM on muuten Drupalin kanssa erittäin hyvää pataa, joten yhteistoimintakin varmasti sujuu. Yliopistolla on kuitenkin hyviä syitä siihen miksi jokainen laitos ei voi touhuta ihan millä työvälineillä nyt sattuu huvittamaan. Järjestelmävalinta Helsingin yliopiston kokoisessa organisaatiossa (50 000 käyttäjää) on muutenkin sen tason asia, että siinä korostuvat esim. integraatio-, suorituskyky- ja skaalautuvuusasiat siinä määrin, että muuten hyvät järjestelmät voivat jäädä paitsioon. Täten ei pidä vetää johtopäätöksiä, että Drupal olisi jotenkin huono isoille organisaatioille vaikka HY ei sitä valinnutkaan. Ja toisinpäin, Oraclen välineet eivät varmasti sovellu monelle keskisuurelle organisaatiollekaan vain sen perusteella että HY päätyi Oracleen.
Mitä tulee viittaukseesi Almaan, niin suosittelen että luet lähteen uudestaan. Almalla ja nyt valituilla Oraclen järjestelmillä ei ole mitään tekemistä keskenään. Uusi sähköinen työpöytä tulee toki korvaamaan Alman jossain vaiheessa. Kannattaa lukea projektiblogia aiheesta jos projekti kiinnostaa: *linkki poistettu toimimattomana*
Sivukommenttina: HY:n Alman dissaaminen on hyvä esimerkki siitä miten huono maine lähtee kiertämään helposti jos käyttöönoton ensimmäiset kuukaudet menevät päin helvettiä. Alma on myös hyvä esimerkki siitä miten yleistä ja helppoa on dissaamisen ja paiskomisen jatkaminen vaikka kovia syitä ei tähän enää olisikaan (Alma on vuosien varrella kehittynyt valtavasti ja on tänä päivänä yksi komeimpia intranet-palveluita Suomessa).
Simo Hellsten
Helsingin yliopiston tietojenkäsittelytieteen laitos muuten julkisti ihan äskettäin uuden www-sivustonsa. Siellä hyrrää alla Drupal eikä Oracle. Ja jo pidempään opetuksen tukena on toiminut avoimen lähdekoodin Moodle.
Tuota Oraclea näytetään lähteenmukaan toistaiseksi yhdistellyn yliopiston Alma-sivustoon, jota saman yliopiston ohjelmistotuotantoon liittyvillä peruskursseilla on toisinaan käytetty konkreettisena esimerkkinä epäonnistuneesta projektista.
Noin isossa organisaatiossa ei taida löytyä yhtä yksittäistä käsitystä siitä mikä ohjelmisto sopii mihinkin.
Simo Hellsten
Ok. Oli huonosti luettu. Kyse siis ei ollut Oraclen systeemin yhdistämisestä nykyiseen Alma-sivustoon, vaan linkin takana luki, että ”Hankkeessa on tähän mennessä mm. uusittu Alman ja intrenetsivuston hakukone ja otettu käyttöön kävijätilastointi sekä intranetissä että internetissä.” Eli Oraclen tuotteita siis otettaneen käyttöön linkitetyn jutun jälkeen.
Perttu Tolvanen
Hakukoneeksihan HY valitsi Googlen Search Appliancen, eli itselle asennettavan palvelimen joka nyt pyörittää tuota helsinki.fi/yliopisto/ -saitilta löytyvää hakua (boksi sivun alareunassa). Käsittääkseni on käytössä myös Almassa nykyisin – tai ylipäätään vastaa yliopiston sisäisestä hakukoneesta johon varmaan hiljakseen kytketään yhä enemmän yliopiston tietovarastoja.
Web-analytiikkavälineeksi ainakin julkisella puolella näytetään ottaneen Google Analytics ja Almassa veikkaisin, että pyörii Googlen paikallisesti asennettava Urchin-tuote.
Google lienee hakukoneena kustannustehokas etenkin HY:n kaltaisessa tilanteessa jossa he halusivat ennen isompaa uudistusta hankkia stand-alone hakukoneen ja kustannukset olivat tärkeä tekijä varmasti. Dokumenttimäärien kasvaessa Google kallistuu ja lähestyy raskaampia kilpailijoitaan hinnoittelun osalta.
HY:llä voi olla tulevaisuudessa pohdinnan paikka esimerkiksi siirtymisessä avoimen lähdekoodin Solr-hakukoneeseen jonka kanssa valtavien datamäärien lisenssikustannukset eivät ole samalla tavalla ongelma. Tosin tuskinpa tuota asiaa nyt ihan lähivuosina tarvitsee vielä HY:ssä miettiä.
Web-analytiikan osalta taitaa avoimen koodin vaihtoehdot olla vielä aika hiljaista monen vuoden ajan.
Simo Hellsten
No, en osaa sanoa mitään web-analytiikan laatukriteereistä, mutta avoimista ainakin AWStats näyttää monipuoliselta ja on ollut kuvioissa jo muutaman vuoden ajan. (awstats.sourceforge.net)
Mikko Ohtamaa
@Perttu Tolvanen: Oxfordin yliopisto on myös aikeissa siirtyä Solr-hakuun. Haku ei tule kattamaan, pelkästään nettisivuja, vaan myös julkaisuarkiston ja henkilöiden yhteystiedot.
Täällä esimakua:
ora.ouls.ox.ac.uk/
Solrissa hyvä puoli on se, että sen sisältöä voi myös ”kuluttaa” (consume) eri järjestelmissä suhteellisen helposti. Eli voit tuoda julkaisujärjestelmiin sisältöä ”sivuina” suoraan Solr-indeksistä.
satunnainen
Syystä tahi toisesta vielä julkaisematon kommentti tuli sähköpostiini. Viestissä käsiteltiin Plonea ja sen kehittäjilä Täytyy myöntää että jo varttuneena olen samaa mieltä: Useiden tuoreempien järjestelmien yhteisö on järkyttävän sulkeutunutta. Ei pahalla ketään kohtaan, mutta erityisesti Drupalin yhteisö tuntuu olevan äärimmäisen sisäänpäinkääntyneitä (järjestelmien suhteen). Hyvä se on naureskella saitille joka on rakennettu Sharepointille vuonna 2003. Rohkeasti vaan vintage Drupal alle ja tekemään ko. saittia sillä. Jos jossain hostingissa vielä PHP 4 on.
“Vuoden web-aiheinen blogi”. Kiitos Tietoviikko. – Vierityspalkki.fi
[…] ovat olleet mm. allekirjoittaneen jutut avoimen lähdekoodin julkaisujärjestelmistä (vahvuudet ja heikkoudet, top-10 järjestelmät Suomessa 2010) ja hakukoneoptimoinnin perusteet sisällöntuottajalle. Muita […]
Ja valittu julkaisujärjestelmä on…tadadadaa: Drupal! « Meri-Lapin museot -verkkosivusto… lab 2.0
[…] järjestelmä, jolla on kehittäjiä paljon. Tästä toki voi olla eri mieltä ja moni onkin ihan hyvin argumentein. Suurin puute avoimessa julkaisujärjestelmässä on mielestäni tietoturvan heikkous, etenkin […]