Avoin lähdekoodi ja APIt

Fuugin säätiö rahoitti tutkimustani, jonka tavoitteena oli selvittää miten APIen aikakautena käy aiemmin menestyksekkäälle avoimelle lähdekoodille. Tutkimus levittäytyi pitkälle ajanjaksolle sisältäen noin 150 artikkelin lukemisen (kuratoitu lista) ja useita ohjelmistokehittäjien, yrittäjien ja tutkijoiden haastatteluja. Tutkimusmatka jatkuu edelleen ja olenkin päätynyt tekemään toisen väitöskirjan APIen kehittäjäkokemuksen liiketoiminnallisesta merkityksestä. Rahoituksen turvin pääsin aloittamaan myös 100 Days DX blogisarjan, joka päättyi 6.11.2019.

Avoin lähdekoodi muutti ohjelmistotaloutta

Avoin lähdekoodi on kiistatta muuttanut maailmaa. Kaikki tunnemme hyvin Torvaldsin Linux tarinan ja vaikutuksen avoimen lähdekoodin menestykseen. Useimmat meistä tietävät nimeltä myös ainakin Apachen ja MySQL:n. Viime vuosina aiemmin suljettuun koodiin nojautunut Microsoft on muuttunut avoimen lähdekoodin puoltajaksi ja edistäjäksi. Joidenkin tutkimusten ja tulkintojen mukaan Microsoft on nykyään eniten avoimeen lähdekoodiin kontribuoiva yritys. Näin ollen voi sanoa, että avoin lähdekoodi on kiistatta muuttanut liiketoimintamalleja, isoja ja pieniä yrityksiä ja ajattelumalleja.

Lisensseistä palveluihin

Samalla liiketoimintamallit ovat muuttuneet lisensoiduista sovelluksista palveluiden myyntiin. Ihmiset eivät enää niinkään halua omistaa, jota lisenssin ostaminen käytännössä on. Sen sijaan haluamme ostaa pääsyn palveluun ja sen tarjoamiin sisältöihin. Tyypillisimmät esimerkit löytyvät viihdemaailmasta: Netflix ja Spotify. Se mikä tänään on normaali, on yhä nopeammin huomenna jo historiaa. Elämme nopeutuvassa syklissä, jossa teknologiaa otetaan käyttöön yhä nopeammin ja samalla toimintatavat muuttuvat.

Avoimen lähdekoodin kulta-aikaa on vaikea rajata, mutta vuosituhannen vaihteen aikoina se alkoi. Nyttemmin APIen ja alustatalouden aikana tilanne on muuttunut. Ennen puhuttiin avoimuuden kohdalla juurikin lähdekoodista. Sittemmin vaatimukset ovat koskeneet dataa (avoin data). Sekin trendi hiipui, muttei hävinnyt mihinkään vaan jäi elämään osana arkeamme. Samoin käy avoimelle lähdekoodille.

Alustojen kohdalla, joiden osia menestyksekkäimmät rajapinnat ovat, eivät kehitä kyvykkyyksiään keskeisiltä osin avoimella lähdekoodilla. Poikkeus on julkinen sektori, joka oletuksena teettää ohjelmistoja avoimella lähdekoodilla. Tosin juuri tarkastetun väitöskirjan mukaan julkisenkin sektorin tulisi ostaa IT -ratkaisut palveluna, jottei ratkaisut happane ennen käyttöönottoa.

APIt osana ohjelmistoa paikallisesti

Nykyaikainen palvelukehitys ei perustu enää niinkään koodikomponenttien yhteenliimaamiseen omalla koodilla. Näinhän ennen toimittiin; poimittiin avoimen lähdekoodin ratkaisuja ja koostettiin niistä oma palvelu. Yhteenliimaamista vaikeutti ohjelmointikielien sekamelska, joka osaltaan pakotti jo silloiset ohjelmistokehittäjät tuottamaan rajapintoja. Tällöin puhuttiin enemmän ohjelmiston sisällä käytettävistä rajapinnoista, joihin ei päässyt käsiksi internetin yli. APIt tulivat osaksi ohjelmistokehitystä jo kauan ennen kuin Roy Fielding julkaisi vuonna 2000 kuuluisan väitöskirjansa REST -rajapinnoista.

APIt löysivät tiensä internetiin

Alustoissa ja API-taloudessa rajapinnan koodin avaamisella ei ole palveluntarjoajalle juuri mitään hyötyä. Eikä sen suhteen API -palvelun hyödyntäjällekään. APIt ovat yksi abstraktiokerros ja useasti menee sekaisin applikaatio, API ja integraaatio.

Itse APIn toteutus on monesti integraatioita omiin järjestelmiin, ostettuihin suljetun lähdekoodin järjestelmiin tai ulkoisiin API-palveluihin. Sen avaaminen kaikille tuskin tuottaa enää samaa lisäarvoa verrattuna siihen mitä se oli aikana, kun koko järjestelmä kaikkine koodeineen avattiin.

Nyt ohjelmistoja koostetaan käyttäen hyväksi omia ja toisten tuottamia rajapintoja. Data ja toiminnot löytyvät rajapintojen kautta. Avoimuus on siirtynyt seuraavalle tasolle.

Avoimuus on rajapintojen ja myös ohjelmistojen kohdalla sitä, että rajapintojen koneluettavat kuvaukset ovat avoimesti saatavilla yhä useammin. Sen avulla APIa hyödyntävä ohjelmoija voi niin halutessaan toisintaa rajapinnan omaan ympäristöön kehitystyötä varten, käyttää kuvausta API-testausohjelmistossa (esim Postman) opetellessaan rajapinnan toimintaa tai vaikka generoida osan itse tarvitsemastaan ohjelmistokoodista.

Koneluettava kuvaus rajapinnasta on noussut merkittävimmäksi avoimesti saatavilla olevaksi resurssiksi. Miksi näin? Syy löytyy rajapintojen tuottamismallista.

Design-lähtöisesti

Yhä useammin APIt tuotetaan ns design-first periaatteella. Siinä hyväksikäyttäen koneluettavaa API-kuvausta suunnitellaan APIn toiminnallisuus koodaamatta vielä mitään. Nykyään yleisin REST APIen kuvaus perustuu OpenAPI spec -formaattiin, joka on avoimesti Githubia käyttäen yhteisöllisesti kehitettävä standardi.

Samasta kuvauksesta voidaan automaattisesti tuottaa testirajapinta asiakkaiden kokeiltavaksi. Saadun palautteen perusteella muokataan koneluettavaa kuvausta. Vasta kun ollaan tyytyväisiä kuvaukseen, laitetaan API toteutukseen.

Samasta koneluettavasti kuvauksesta voidaan joko osittain tai kokonaan automaattisesti avoimen lähdekoodin työkaluja käyttäen tuottaa APIn dokumentaatio. Koneluettavan kuvauksen monikäyttöisyys osana kehittäjäkokemuksen luomista, APIen suunnittelua ja dokumentaatiota on tehnyt siitä keskeisen elementin.

Työkalut avointa lähdekoodia

Monesti APIen toteutukseen käytetään avointa lähdekoodia. Useat suositut ohjelmistokehikot (framework) ovat avointa lähdekoodia.

Vaikka alustat ja APIen tarjoajat eivät omaa lähdekoodiaan enää avaa, niin avoin lähdekoodi on edelleen vahvasti läsnä. Kehittäjät rakastavat avointa lähdekoodia ja heillä on kyky tehdä osana omaa työtään lisää työkaluja. Näin ollen avoimuus API- ja alustataloudessa näkyy työkalujen avoimena lähdekoodina.

Entä tulevaisuus?

Erityisesti suositut alustamaisesti toimivat API-vetoiset palvelut kuten Stripe ja Sendgrid ovat siirtyneet rajapinnoista kirjastovetoiseen toimintaan. Sen sijaan että tarjottaisiin rajapintoja, tarjotaan tuotteistettuja ohjelmistokirjastoja (library) suosituille kehitysalustoille. Osasyynä on kehittäjäkokemuksen optimointi. Ohjelmistokirjastojen avulla palveluiden käyttöönotto verrattuna APIen käyttöön on mahdollista tehdä todella helpoksi. Esimerkkinä tästä on Stripe joka mahdollistaa oman palvelunsa käyttöönoton 6 rivillä koodi.

Ohjelmistokirjastot luovat jälleen yhden abstraktiokerroksen yksinkertaistaen palvelun käyttöönottoa entisestään. Ero aiemmin jo ohjelmistotaloudessa olleisiin kirjastoihin on se, että nykyaikaiset versiot hyödyntävät taustalla internetin kautta saavutettavia rajapintoja. Ohjelmistokirjastot puolestaan ovat hyvin usein avointa lähdekoodia. Seuraus on ollut että on syntynyt joskus kymmeniä vaihtoehtoisia kirjastoja samalle palvelulle.

Ohjelmistokirjastot eivät mahdollista samaa joustavuutta kuin APIen ”raakaversiot”. Usein kirjastot sisältävät tyypillisimmät palvelun hyödyntäjän tarvitsemat toiminnot kompakteina helppokäyttöisinä sisäisinä rajapintoina. Lopputuloksena on usein usean kerroksen API -ketju, jossa osa rajapinnoista on paikallisia ja osa internetissä toimivia.

Yhteenvetoa

Avoin lähdekoodi ei ole kadonnut tai katoamassa API- ja alustatalouden nousun myötä. Avoin lähdekoodi ja avoimuus jatkavat menestystään, mutta eri kerroksessa useimmiten lähempänä loppukuluttajaa eli tässä tapauksessa sovelluskehittäjää.

Jätä kommentti