Here at Dude, we use the same database for the site’s all development and staging environments. With this neat arrangement, we always have the latest content shared between our developers, which is crucial as the team might be working on the same project at the same time. No need for database migrations or moving dump files. Backend developer can just tell to frontend developer that the new page is there and needs styling.

Earlier today I needed to get posts across the entire WordPress Network installation into ACF post object field. To my surprise, this isn’t possible with ACF itself and few plugin implementations found from Github were abandoned or didn’t fit fully to my needs.

So what developer does in this kind of situation? Writes a plugin that adds a new field type.

During the last six months, I’ve been thinking more and more how grateful I am for being able to contribute to the WordPress project. It has taught me so much on so many levels. Helping event organizers allows me to go (virtually) around the world and learn from different cultures. I get to work with amazing and super talented persons. New friendships and connections have been established. I’ve been trusted to take care of complex things and resolve those on my own.

It always gives a long-lasting good feeling, when you see someone you helped to make a blast out of their event or success in their contribution. But the utmost valuable thing has been endless warmth and respect for each other. Even if we wouldn’t always agree, everyone’s opinion is heard and taken into consideration. We work together towards the same goal.

Without my involvement in the project and without the discussion with thoughtful individuals, I wouldn’t be the person I’m today. WordPress project has given me the feeling of being part of something bigger and far more important than I’ve felt ever before, although I have been involved in too many soups to this age.

For a few years now, there has been silent, but a continuous bad feeling in my head about how much I use and depend on services of Google and Facebook. I’ve have fantasized about the idea of burning the bridge between me and these two giants. But as said before, my everyday life really depends on their products. Even thinking the amount of work on burning bridges has gotten me forget the plans.

Kirjoitus on julkaistu alunperin Duden blogissa.

Duden blogissa on puhuttu viimeaikoina suhteellisen paljon siitä, paljonko nettisivut maksavat ja mistä se hinta sitten koostuu. Jokaisessa kirjoituksessa olemme kertoneet sivuston olevan aina räätälöity 100% asiakkaan tarpeita varten, tuo räätälöinti ulottuu aina visuaalisesta ilmeestä syvälle konepellin alle.

Roni tiivistikin aiemmin osuvasti tuota konepellin alla olevaa osuutta. Ajattelin nyt avata tätä teemaa hieman enemmän näin back-end kehittäjän roolissa kahdessa erillisessä kirjoituksessa.

Kehitämme projektia mieluusti eteenpäin ja ainakin rakennamme sivustomme sellaiseksi, että niitä pystyy kehittämään eteenpäin.

Ensimmäisessä osassa käsittelen tietorakenteen suunnittelun tärkeyttä ja kerron miten me Dudella hoidetaan asia. Seuraavassa osassa kerron minkä takia ja miten kiinnittää huomiota myös hallintapaneeliin.

Kävijä näkee sivustosta ainoastaan ns. julkisen puolen, sen miltä kaikki tieto näyttää hienosti ja visuaalisesti aseteltuna. Tuskinpa kukaan tulee ajatelleeksi millä tavalla jokin tieto on tallennettu tietokantaan tai minkälaisilla palikoilla visuaalisuus on kasattu.

Käytännössä projektin koodaamisen aloitus alkaa aina tietorakenteen suunnittelusta. Yhtään riviä koodia ei kirjoiteta, ennen kuin tietorakennetta on mietitty vähintään päässä, mieluusti jopa analogisella paperilla.

Miksi suunnitella tietorakennetta?

Selkeyden vuoksi samaan asiaan liittyvän tiedon hallinnoiminen on hyvä olla mahdollista yhdestä paikkaa. Sivuston sisällön ylläpitäjälle on paljon selkeämpää päivittää yhden ominaisuuden kuvausta itse ominaisuuden muokkasnäkymästä, kuin erikseen jokaisella sivulla missä kyseinen ominaisuus näkyy tavalla tai toisella.

Tietorakenteen suunnittelu liittyy hallintapaneelin käyttömukavuuden ja selkeyden lisäksi vahvasti jatkokehityksen ennakointiin. Kuvitellaan tilanne, jossa esimeriksi ominaisuuksia listataan ainoastaan etusivulla ja etusivulle on luotu lisätietokentät ominaisuuksien lisäämistä varten. Mitä sitten kun asiakas haluaakin listata ihan samoja ominaisuuksia, edes osaa niistä muilla sivuilla tai jokaiselle ominaisuudelle oman laajan esittelysivun?

Kaikki aiempi ominaisuuksiin liittyvä back-end koodi muuttuu turhaksi ja hommat joudutaan tekemään tältä osin nollasta uusiksi. Jos tietorakennetta on taas mietitty etukäteen edes hieman ja luotu ominaisuuksille oma sisältötyyppinsä (custom post type, CPT), on homma todennäköisesti paljon kivuttomampi.

Miten Dude tekee tämän käytännössä?

Projekti käydään vielä kerran läpi yhdessä graafikon kanssa, jotta saadaan vastauksia seuraaviin kysymyksiin: minkälaisia sisältötyyppejä sivustolle tarvitaan? miten sen artikkelit jäsennellään? tarvitaanko kategorioita? onko sisältötyypillä arkisto tai sen yksittäisillä artikkeleilla julkista näkymää? linkittyykö joidenkin sisältötyyppien tiedot keskenään? mikä on sisältötyypin osoiterakenne (slug)? mikä on koko projektin kaiken sisällön osoiterakenne?

Vasta kun nämä asiat alkaa olla selvillä, aletaan kasaamaan sisältötyyppejä, niiden lisätietokenttiä (metadata) ja sivupohjia.

Käytännössä Duden back-end kehittäjän workflow lisäkenttien luomiseen ja sivuston julkiselle puolelle saamiseksi on seuraava:

1. Huomataan että esimeriksi etusivulla on nostoja tuotteen ominaisuuksista ja jokainen nosto sisältää otsikon, ikonin sekä lyhyen kuvauksen.
2. Selataan leiskat läpi ja katsotaan onko joillain toisella sivulla samanlainen elementti tai samat sisällöt esitettynä hieman eri tavalla.
3. “Ahaa, kaikki ominaisuudet esitellään yhdellä koontisivulla ja siellä näyttäisi olevan sama otsikko sekä ikoni, mutta eri kuvaus ja erilainen visuaalisuus.”
4. Luodaan ominaisuus -sisältötyypin artikkelille lisätietokentät ikoni, lyhyt kuvaus, lyhyt kuvaus etusivun nostossa ja käytetään otsikkona ominaisuuden nimeä.
5. Luodaan etusivulle lisäsisältökenttä josta voi valita nostettavat ominaisuudet, tai vaihtoehtoisesti luodaan yksittäisen ominaisuuden muokkaukseen valinta tätä varten. Tapa riippuu hieman siitä, miten etusivun muu sisältö rakentuu ja tarvitaanko ominaisuusnostoja myös muualla.
6. Luodaan teemaan osat (template part) erikseen yksittäisen ominaisuuden nostolle koonti- ja etusivulla. Näissä käytetään edellä mainittuja lisätietokenttiä. Ensimmäistä osaa käytetään ominaisuuksien koontisivun listassa ja toista etusivulla.
7. Teeman osissa tulostetaan kaikki olennaiset tiedot, tässä tapauksessa otsikko, edellä mainitut lisätietokentät ja yksittäisen ominaisuuden osoite ilman html-rakennetta (poislukien kuvien, otsikoiden ja linkkien html tagit).

Sama rumba toistetaan sivupohja kerrallaan ja sivun elementti kerrallaan.

Käytännössä Duden työmallilla, jossa jokaisessa projektissa on erikseen back-end ja front-end kehittäjät, sivuston julkinen puoli näyttää hyvin rujolle näiden työvaiheiden jälkeen, ennen kuin front-end kehittäjä rakentaa asettelun visuaaliseen muotoon. Kaikki sisältö on näkyvissä kuten kuuluukin, mutta ei kovin nätisti.

Front-end kehittäjä rakentaa projektista riippuen html-rakenteen ja css-tyylit sisällön ympärille ennen tai jälkeen taustatyön, usein antaen lisätehtäviä, korjaustöitä tai muita muutoksia back-end kehittäjälle. Loppu projektista etenee siis samaan aikaan front-end sekä back-end kehittäjän pöydillä yhteistyötä tehden.

PS. Ollaan Ronin kanssa höpöttämässä marraskuussa Tampere WordPress Meetupissa meidän tavasta tehdä sivustoja, tulehan ihmeessä paikalle!

Kirjoitus on julkaistu alunperin Duden blogissa.

Suomalaiset WordPress-kehittäjät sekä -käyttäjät kokoontuivat kolmatta kertaa yhteen täydeksi seminaaripäiväksi sekä lauantain työpajoihin WordCamp Helsinki 2017 tapahtumaan. Koko Duden edustus oli paikalla (kyllä, koodipuoli sai suostuteltua graafisen osaston aamujunaan) ensimmäistä kertaa, kahtena aiempana vuonna ainoastaan koodarit olivat mukana. Allekirjoittanut ei itseasiassa ollut osallistuja, vaan yksi henkilö kolmatta kertaa järjestetyn tapahtuman takana.

Roni kirjoitti mainioin koosteen ensimmäisestä vuonna 2015 järjestetystä WordCampista, johon itse osallistuin vielä toisen yrityksen palkkalistoilta. Toisena vuonna olinkin jo Duden palkkalistoilla sekä vapaaehtoisena auttamassa WordCampin pääpäivänä, tuolloinkin kertaa Roni kirjoitti kattavan koosteen menosta. Tällä kertaa ajattelimme jättää koosteet sikseen ja pistää minut kirjoittamaan kokemuksesta olla järjestämässä WordCampia ensimmäistä kertaa. Inspiraatiota antoi Sami Keijosen viimevuotinen kirjoitus samalla kulmalla.

Tiimi kasaan ja suunnittelu käyntiin

Tämän vuoden WordCampin suunnittelu alkoi jo syksyllä 2016 kun yhteisöstä alettiin etsimään halukasta kaupunkia, pääjärjestäjää sekä tiimiä. Pallottelua käytiin paljon Jyväskylän ja Turun välillä, toivoen seuraavan WordCampin suuntaavan jälleen uuteen kaupunkiin. Pääjärjestäjiä ja tiimejä ei kuitenkaan löytynyt näistä kaupungeista, joten Niko Pettersen ja Helsingin yhteisö otti kopin loppuvuodesta.

Pääjärjestäjänä toimineen Nikon ympärille löytyi nopeasti tiimi edellisen WordCampin järjestäjistä ja Jyväskylän sekä Turun kiinnostuneista järjestäjistä. Tässä vaiheessa onkin mainio hetki antaa iso kiitos tyypeille jotka tekivät WordCampin kanssani; pääjärjestäjä Niko, Kenda, Kirsi, Marco, Mayank, Sami, Sonja ja Teemu. Teidän kanssa työskentely oli huippua!

Kaupungin päättämisen ja tiimin kasaamisen jälkeen oli aika laittaa iso pyörä pyörimään. WordCampit eivät nimittäin synny pelkästä yhteisön aktiivisuudesta, vaan taustalla on satoja tunteja työtä sekä byrokratiaa. Niin, byrokratiaa. Vaikka WordPressiä saa sekä voi käyttää kuka tahansa ja yhteisö on hyvinkin vapaamuotoinen, WordCamppeja ei voi järjestää kuka tahansa “virallisella” nimellä kutsuen sitä WordCampiksi ja saaden tukea kansainväliseltä yhteisöltä.

WordCamp Centralille jätetään hakemus jossa kerrotaan yhteisön taustoista, järjestäjätiimistä sekä vastataan suurin piirtein 20 kysymykseen joilla kartoitetaan valmiuksia järjestämiseen. Koska suomessa oli järjestetty jo kaksi aiempaa WordCamppia ja WordCamp Centralin Jenny Wong oli jo näyttänyt alustavaa vihreää valoa, uskalsimme aloittaa tapahtumapaikan etsimisen ilman virallista Centralin hyväksyntää.

Hakemuksen hyväksymisen jälkeen suunniteltiin tapahtuman budjetti ja hyväksytettiin se vielä erikseen WordCamp Centralilla. Budjetti on sen verran monimutkainen asia, että en edes lähde selostamaan siitä. Knoppitietona kerrottakoon kuitenkin budjetin olleen karvan verran yli 13 000 euroa.

Tapahtumapaikka

Kokopäivän seminaaria järjestäessä suhteellisen pienellä budjetilla, tapahtumapaikalle asettuu yllättävän monta kriteeriä: ns. tapahtumainfran on oltava suhteellisen valmiina tai paikan tulee hoitaa kaikki tuolien vuokraamisesta aina lavaan ja lavatekniikkaan saakka, lavalle tulee olla kaikkialta hyvä näkyvyys, sponsoreille sopivaa tilaa tulee löytyä, kahvien ja lounaan tulee järjestyä ilman suuria lisäpanostuksia ja kommunikaation on toimittava hyvin tapahtumapaikan edustajan kanssa.

WordCamp Helsinkiä järjestäessä varovaisena tavoitteena oli kasvattaa osallistujamäärää hieman ja ehkä saada kaksi lavaa, koska jo edellisvuoden kokemusten perusteella odotettiin suurta kysyntää.

Sami kartoitti mahdollisia paikkoja suhteellisen intensiiviset pari viikkoa etsien tilaa, jossa olisi varaa laajentua, mutta ainakin iso osa tarvittavasta tapahtumatekniikasta olisi valmiina. Ja tietenkin budjettiin sopivalla hinnalla. On muuten yllättävän hankalaa, joten päädyttiin Virgin Oiliin joka toimi myös WordCamp Finland 2016 tapahtumapaikkana ja yhteistyön tiedettiin sujuvan ensiluokkaisesti.

Jälkiviisana voi todeta, että meidän olisi ehkä pitänyt olla vähän rohkeampia ja valita paikka, joka olisi ollut kalliimpi ja vaatinut enemmän järjestelyjä tekniikan sekä lounaan suhteen. Liput myytiin nimittäin loppuun minuutin päälle kahdessa tunnissa.

Puhujat

Jokaisella järjestäjällä oli oma vastuualueensa tai vähintään tuki/takahenkilön rooli, muutamilla useampi rooli. Itse vastasin tapahtuman puhujavalinnoista, esitysten sisällöistä ja oikeastaan lähes kaikesta puhujiin liittyvästä. Sen lisäksi kilpailutin ja tilasin tapahtuman oman swagin, jonka Sonja suunnitteli.

Oikeastaan puhujista vastaaminen ei ole pelkästään heidän valitsemista, ohjeistamista, esitysten läpikäymistä ja tapahtumapäivänä heistä huolen pitämistä. Puhujista vastaavan henkilön harteilla on myös pitää huoli järjestäjätiimin kanssa sovittujen aihepainotusten toteutumisesta sekä esitysten monipuolisuudesta. Koska WordCamp Helsinki on vuoden ainoa suuri WordPress-tapahtuma, haluttiin ohjelmiston olevan mielenkiintoinen niin sisällöntuottajille, projektipäälliköille kuin myös seniorillekkin devaajalle. Toivottavasti tässä onnistuttiin.

Kirjoitin puhujavalintaprosessista ja kriteereistä aiemmin WordCamp Helsingin blogiin, joten en lähde avaamaan niitä tässä sen enempää. Kerrottakoon kuitenkin, että saimme 35 ehdotusta esityksistä yhteensä 28 ihmiseltä ja tapahtumaan pystyttiin valitsemaan 12 puhujaa.

Välittömästi puhujavalintojen varmistumisen jälkeen alkoi tiivis kommunikaatio puhujien kanssa. Aikataulujen varmistelua, ohjeita laadukkaan esityksen tekemiseksi, käytännön asioiden viestittämistä, esitysten jalostamista yhteistyössä ja niin edelleen. Omalta osaltani kiireisin aika alkoi puolitoista kuukautta ennen tapahtumaa, sillä kaiken edellämainitun lisäksi piti diilata swagitilausten sekä tapahtuman aikataulun rakentamisen kanssa.

Itse tapahtuma

Pariin yöhön ei meinannut tulla uni, kun stressasi ja jännitti niin paljon, olihan vastuullani kuitenkin tapahtuman onnistumisen kannalta yksi tärkeimmistä asioista.

Tapahtuman rakentaminen aloitettiin torstaina alkuillasta, kun pääsimme Virgin Oiliin pörräämään, laittamaan tavaroitamme paikoilleen, varmistelemaan seuraavan päivän kulkua henkilökunnan kanssa sekä vihdoin tapaamaan kaikki puhujat, vapaaehtoiset sekä paikalliset sponsorit kasvotusten.

Sitten koitti perjantai, aikainen herätys ja tapahtumapäivä. Heti matkalla sain harmikseni viestin, että Viljami Kuosmanen on kipeänä eikä pääse puhumaan. Bussissa asialle ei voinut kauheasti muuta, kuin kommunikoida asia muulle tiimille ja alkaa miettimään mistä löytää uusi puhuja Viljamin tilalle. Jännitystä lisäsi myös Aki Björklundin edellisiltana tullut viesti, että hänkin on kipeänä ja ei pysty 100% varmuudella takaamaan tulemistaan.

Ennen ovien aukeamista säädettiin vielä aivan viimeisiä asioita kasaan Virgin Oilissa, etsittiin ratkaisua puhujatilanteeseen sekä juotiin kahvia. Paljon. Ovien auettua alkoikin täysi tohina rekisteröintitiskillä, puhujia sekä sponsoreita vastaanottaessa sekä lukuisia tuttuja morjestaessa. Aamupalaksi tilatut leivät eivät itselle uponneet kaiken jännityksen sekä innostuksen keskellä, kävijöille näytti kuitenkin maistuvan!

Ilokseni ja onnekseni heti aamulla muutama henkilö ilmoittautui vapaaehtoiseksi puhumaan jos joku puhujista ei pääse paikalle. Näin saimme Petya Raykovskan, joka muuten järjestää WordCamp Europea, paikkaamaan Viljamia. Aamupäivän aikana varmistui myös Akin pääseminen paikalle, joskin puolikuntoisena. Ei voi muuta ku hattua nostaa Petyalle ja Akille! Kaikki muutkin puhujat ansaitsevat suuren suuren kiitoksen.

Kaikki esitykset meni itseltäni enemmän tai vähemmän ohi, koska suhasin ympäri tapahtumapaikkaa, huolehdin puhujien viihtyvyydestä sekä valmistelusta lavalle, aikataulussa pysymisestä ja kaikenlaisista muista pienistä asioista. Olen vaan luonteeltani sellainen, että järjestäessä stressaan ja murehdin niitäkin asioita jotka eivät ole vastuullani, vaikka tiedänkin luotettavan henkilön vastaavan niistä. Isona apuna puhujien viihdyttämisen ja valmistelun sekä aikataulun kanssa oli lavamanagerit Sami ja Liisa, kiitos teille! Onneksi voin katsoa kaikki esitykset myöhemmin WordPressin televisiosta.

Aikataulullisesti pyrimme antamaan enemmän aikaa osallistujien keskinäiselle jutustelulle ja verkostoitumiselle, mikä onnistui ehkä liiankin hyvin. Muutaman hieman suunniteltua lyhyemmän esityksen ja sattuman takia tauot olivatkin pidempiä kuin olimme suunnitelleet. Ainakin järjestäjänä ns. tyhjää aikaa tuntui muodostuvan jonkin verran liikaa.

Kaikenkaikkiaan koko järjestäjätiimi tunsi tapahtuman onnistuneen hyvin, toivottavasti kävijöillä oli samanlainen fiilis! Tavoitteena oli kuitenkin järjestää mukava ja rento, mutta asiapitoinen tapahtuma jossa kaikki viihtyvät.

Speaker’s dinner, afterparty ja contributor day

Virallisen ohjelman loputtua ja nopean tapahtumapaikan purkamisen jälkeen suuntasimme puhujien, vapaaehtoisten sekä järjestäjien kanssa SMYGiin syömään. Oli hyvvee ja tältä suunnalta irtoaakin vahva suositus SMYGin ensiluokkaiselle palvelulle sekä todella maittavalle sapuskalle!

Illasta jatkui vielä virallinen ohjelma afterpartyn merkeissä, josta meni taas iso osa itsellä ohi koska tyypilliseen tapaani pörräsin huolehtimassa asioista joista ei välttämättä olisi tarvinnut edes stressata. Tästä huolimatta ilta oli oikein mukava ja siihen mahtui muutamia todella hyviä keskusteluja sekä paljon lyhyitä kohtaamisia. Muut duden pojat saikin kuulemma osakseen enemmän juttuseuraa, huomiota ja taputuksia olalle. Paljon kuulemma vaihdettiin juttua meidän alalle ehkäpä epätyypillisestä, erilaisesta ja rouheasta meiningistä. Aina on jotenkin jännä kuulla, miten Dudea fiilataan vaikka itse koetaan ainoastaan tekevämme töitä kuten tykätään, eikä olla suunnitelmallisesti tai tarkoituksella erilaisia.

Virallisen afterpartyn jälkeen käytiin vielä kollegoiden kanssa nappaamassa muutamat yömyssyt, kylläpä muuten upposi!

Lauantaina aamua aloiteltiin hotellin runsaalla aamupalalla, jonka jälkeen muut ukot suuntasi junaan ja minä contributor dayhin. Suurin osa ajasta meni WordCamp Centralin Jenny Wongin ja muiden paikallisten meetuppien (Helsinki, Tampere, Turku, Oulu) järjestäjien kanssa puhumassa kokemuksista, haasteista ja vinkeistä meetuppien järjestämiseen liittyen. Keskustelua käytiin myös tulevista WordCampeista ja niiden järjestämisestä.

Suurimpana contributor dayn saavutuksena taisi olla WordPress.orgin lisäosahakemiston kääntäminen suomeksi.

Mitä seuraavaksi?

Nurkan takana kurkkii jo kesäkuussa Pariisissa järjestettävä WordCamp Europe, joka on tänäkin vuonna maailman suurin yhteisön tapahtuma. Lippuja on vielä jokunen sata saatavilla 😉

Jos kolmetuhatta osallistujaa ja Pariisi ei houkuttele, löytyy ihan kotikulmilta kerran kuukaudessa järjestettäviä WordPress -meetuppeja, tällä hetkellä niitä tapahtuu täällä Jyväskylässä, Helsingissä, Tampereella, Turussa ja Oulussa. Huhujen mukaan Seinäjoellakin alkaa pian meetupit, mikä on aivan mahtavaa! Jos omilta kulmiltasi ei löydy vielä WordPress -meetuppia ja haluaisit asian olevan toisin, tule yhteisön Slackiin #meetups kanavalle ja autamme oman paikallisen meetupin pystyttämisessä 🙂

WordCamp Jyväskylään?

Seuraavassa Jyväskylän meetupissa 13.5. keskustellaan mahdollisuudesta järjestää hieman pienimuotoisempi ja kehittäjille suunnattu WordCamp Jyväskylässä. Tule ihmeessä paikalle jos WordCampin tuominen Keski-Suomeen kiinnostaa! Samalla suunnitellaan tulevia Jyväskylän meetuppeja ja niiden aiheita.

Mielenkiinnolla jään myös odottamaan tapahtuuko seuraava isompi WordCamp Turussa, kuten on hieman uumoiltu viimepäivinä. Vai kerätäänkö 2018 kasaan yksi iso pohjoismainen WordCamp. Selvää on ainakin se, että kiinnostus WordPressiä kohtaan ei ole laskemassa ja yhteisö jatkaa tasaista mutta vauhdikasta kasvuaan!

PS. Jos suomalaisen WordPress-yhteisön syntyhistoria ja stoori ensimmäisen WordCamp Finland tapahtuman järjestämisestä kiinnostaa, kannattaa kuunnella SAWP-podcastin seitsemäs jakso. Vieraana on Daniel Koskinen, jota voidaan pitää suomalaisen yhteisön alkuunpanijana.

Kirjoitus on julkaistu alunperin Duden blogissa.

Viime vuoden puolella kirjoitin vastineen avoimen lähdekoodin WordPressiä ja suljetun koodin ProcessWireä vertailevalle blogaukselle. Tällöin keskityin lähinnä kumoamaan vääriä väittämiä sekä olettamuksia WordPressistä.

Tällä kertaa aion kirjoittaa yleisemmin avoimen ja suljetun lähdekoodin järjestelmien eroista, kumoten Whitestonen blogissa esitettyjä väittämiä sekä tuomalla niihin toista näkökulmaa. On toki syytä muistaa, että Whitestonen päätuote on toteutukset heidän oman suljetun järjestelmän päälle ja Duden päätuote taasen laadukkaasti toteutetut sivustot sekä verkkokaupat avoimen WordPressin päälle.

Yleisesti lienee syytä sanoa, että mielestäni suljetun lähdekoodin järjestelmiä pitäisi välttää mahdollisuuksien mukaan kuin ruttoa.

Suljetun lähdekoodin järjestelmän kanssa olet toimittajalukossa, ja voin kertoa että se lukko ei tunnu hyvälle. Olet poikkeuksetta täysin riippuvainen järjestelmän toimittajasta ja hänen tahtotilastaan kyseisen järjestelmän kanssa. Usein myös maksat siitä että asioita ei kehitetä jatkuvasti, vaan järjestelmää käytetään pelkästään rahantekokoneena kalliiden lisenssi- ja/tai tukimaksujen “ansiosta”.

Kaikkihan tuntee surullisen kuuluisat Tiedon, Accenturen ja muiden vastaavien isojen toimijoiden epäonnistuneet ja kustannuksiltaan kohonneet suljettujen järjestelmien projektit. Avoimen lähdekoodin järjestelmien kanssa näitä ongelmia on hyvin harvoin.

Sitten sukelletaan väittämiin joihin on jotain sanomista, pitäkää penkeistänne kiinni.

Suljetun lähdekoodin keskeisimmiksi eduiksi listattiin mm.

Tietoturvariskien ja muiden haavoittuvuuksien hallitseminen johtuen juuri siitä, että lähdekoodi ei ole avoin kaikille tutkittavaksi.

Ei pidä laisinkaan paikkaansa. Suurin osa järjestelmien haavoittuvuuksista löydetään, vaikka lähdekoodista ei ole nähty pätkääkään. Järjestelmissä on aina erilaisia rajapintoja ja muita liikkuvia osia, joita sinnikkäästi tai onnekkaasti kokeilemalla löytää toisinaan helpostikkin haavoittuvuuden.

Koska ihminen on erehtyväinen, jokaiseen järjestelmään jää luonnollisesti aina haavoittuvuuksia ja tietoturvariskejä. Sen takia ei tule liiaksi tarkastella kuinka paljon niitä löytyy, vaan kuinka niiltä pyritään välttymään ja miten toimitaan kun sellainen löydetään tai raportoidaan.

Uskallan väittää, että avoimen lähdekoodin järjestelmissä on vähemmän haavoittuvuuksia ja tietoturvaongelmia kuin suljetuissa järjestelmissä – ja juurikin koska lähdekoodi on kaikkien tutkittavissa. Tämän ansioista kymmenet, ellei sadat, silmät käy lähdekoodia läpi jo testausvaiheessa ja iso joukko huomaa mahdolliset riskit todennäköisemmin. Suljetun järjestelmän koodia saattaa pahimmillaan käydä läpi yhdet silmät. Eikä ole muuten kerta tai kaksi, kun olen kuullut tutuiltani heidän löytäneen vakavan haavoittuvuuden suljetusta koodista ja kehittämisestä vastaavan yrityksen painaneen asian villaisella. Toisinaan jopa yli puolen vuoden jatkuvan haavoittuvuudesta muistuttelun jälkeen.

Avoimen lähdekoodin järjestelmään jääneet haavoittuvuudet huomataan myös suuremmalla todennäköisyydellä, koska käyttäjä- ja kehittäjäkunta on suurempi. Löydetyt haavoittuvuudet tulee myös korjatuksi nopeammin, koska se ei ole kiinni kenenkään työajan riittävyydestä ja mukana on useampi kehittäjä tekemässä korjausta samanaikaisesti.

Tiivis kumppanuus järjestelmätoimittajan kanssa, yhdessä asetetut pitkän ja lyhyen matkan tavoitteet. Palvelun räätälöinti ja toteuttaminen asiakkaan yksilöllisten toiveiden sekä tarpeiden mukaisesti.
>
Ohjelmistolisenssiin kuuluu virallinen palvelun ylläpito ja muut tukipalvelut.

Avoimen lähdekoodin järjestelmä ei sulje mitään näistä pois, vaan usein jopa mahdollistaa ne paremmin. Toteutus avoimella koodilla ei tarkoita sitä, että lopputulos hylätään projektin valmistumisen jälkeen. Esimerkiksi me Dudella teemme jatkuvasti tiivistä yhteistyötä asiakkaittemme kanssa sivustojen sekä verkkokauppojen jatkokehityksen suhteen. Tarjoamamme ylläpito näkyy harvoin asiakkaalle, sillä kaikki tapahtuu taustalla automaattisesti meidän toimesta. Asiakkaan tarvitessa tukea, vastaamme 90% tapauksista alle puolessa tunnissa.

Räätälöinti ja jatkokehittäminen voi olla suljetussa järjestelmssä hyvinkin hankalaa, jos alkuperäistä koodipohjaa kehittäessä ei ole otettu huomioon tulevaisuuden laajennustarpeita. Harmillisen usein ei ole otettu ja tällöin kustannukset voivat nousta suuremmiksi kuin räätälöinnillä ja jatkokehittämisellä saavutetut edut. Suljetut järjestelmät on usein sidottu myös sitä kehittävän yrityksen palvelininfrastuktuuriin, jolloin huonosta ympäristöstä johtuvan järjestelmän hitauden sekä kaatuilun korjaaminen on hidasta tai jopa olematonta. Avoimen koodin järjestelmän voi siirtää huonolta palveluntarjoajalta toiselle täysin vapaasti.

Suljetun lähdekoodin järjestelmiä toimittavien yritysten asiakaspalvelusta en sano muuta, kuin totean sen olevan usein ala-arvoista. Huonolla tuurilla saat Postiltakin parempaa palvelua.

Avoimen lähdekoodin haasteina nähtiin mm.

Omat tai kolmannen osapuolen järjestelmään tekemät muutokset, jotka aiheuttavat palvelun toimimattomuutta tai aiheuttavat tietoturvariskin.

Täysin sama ongelma on suljetun lähdekoodin järjestelmissä. Ihminen on jälleen erehtyväinen, ja suljetun järjestelmän koodaaja voi källätä rikkoen koko järjestelmän tai huomaamattaan tehdä uuden haavoittuvuuden toteuttaessa uutta ominaisuutta. Oikeastaan asia mikä tässä ratkaisee, on yrityksessä työskentelevien kehittäjien ammattitaito – täysin riippumatta siitä onko lähdekoodi avointa vai suljettua.

Kolmannen osapuolen tekemät muutokset testataan luonnollisesti aina kehitysympäristössä, juurikin sen takia että asiakkaan varsinaista järjestelmää ei hajoteta toimimattomaksi. Jos kehitysympäristössä tulee ongelmia kolmannen osapuolen muutosten takia, ratkaistaan ne joko muuttamalla omaa koodia, tekemällä korjaava fork kolmannen osapuolen koodista sekä raportoimalla ongelma sen kehittäjälle. Ongelma ei pääse missään vaiheessa heijastuman asiakkaalla käytössä olevaan järjestelmään.

Avoimen lähdekoodin mahdollistamat haavoittuvuudet/tietoturvariskit ja niiden aiheuttamat mahdolliset lisä- ja/tai ylläpitokustannukset.

Edellä mainitsemistani syistä, avoimen lähdekoodin järjestelmässä haavoittuvuudet ja riskit on todennäköisesti korjattu jo ennen kuin asiakas edes kuulee niistä. Mikä on hyvä asia – se kertoo korjaamisen nopeudesta. Koska lähdekoodi on kaikkien vapaasti käytettävissä, saa nuo yhteisön tekemät korjaukset käyttöönsä täysin ilmaiseksi. Nimenomaan suljetuissa järjestelmissä päivityksistä voi joutua maksamaan, riippuen toimittajan kanssa tehdystä sopimuksesta.

Avoimen lähdekoodin palvelun kehityksen loppuminen, palvelun suosion, kiinnostuksen tai tekijöiden siirtyessä muualle.

Jos avoimen lähdekoodin järjestelmän kehitys loppuu, voit jatkaa sitä itse – vaikka todennäköisesti järjestelmän suuresta yhteisöstä nousee useampikin henkilö tekemään sitä eikä sinun tarvitse. Suljetun lähdekoodin järjestelmän kanssa olet suoraan sanottuna kusessa, jos sit kehittävä yritys menee konkurssiin tai päättää keskittyä toisen suljetun järjestelmän kehittämiseen. Silloin joudut vaihtamaan koko järjestelmän uuteen, mikä on raskas ja kallis projekti.

Palvelun versioiden yhteensopivuus edellisten versioiden kanssa, koska kehitys on helposti suosion perusteella ohjautunutta.

Varsinkin suosituimmissa avoimen lähdekoodin järjestelmissä versioiden taaksepäin yhteensopivuutta pidetään suuressa arvossa. WordPressin historiasta tulee mieleeni ainoastaan muutama tapaus, jolloin taaksepäin yhteensopivuus on jouduttu hajoittamaan tietoisesti – tällöinkin muutoksista on kerrottu hyvissä ajoin ja isosti, jotta kehittäjillä on aika valmistautua muutokseen. Suljetun koodin järjestelmissä esimeriksi integraatiorajapinnat voivat muuttua mielivaltaisesti lyhyelläkin varoitusajalla ilman varoitusta kehittäjille, tällä voi olla vaikutusta esimerkiksi verkkokaupan maksuväylien toimivuuteen.

Maksulliset lisä- ja tukipalvelut.

On ne lisä- ja tukipalvelut maksullisia suljetunkin koodin järjestelmissä, usein jopa kalliimpia. Yritykset jotka markkinoivat suljettua järjestelmää lisä- ja tukimaksuttomana, ovat leiponeet kyseiset kustannukset kalliisiin lisenssi- ja/tai kuukausimaksuihin.

Sitä paitsi, usein avoimen lähdekoodin järjestelmillä on hyvin aktiivinen yhteisö josta voi saada neuvoa ja tukea etenkin pienemmissä asioissa. Esimeriksi WordPressillä on lukuisia yhteisön ylläpitämiä kanavia tuen tarjoamiseen.

Loppukaneettina todettakoon, että avoin lähdekoodi voitti taistelun jo aikapäiviä sitten.