Tarkvara arendus- ja ärimudel: Linuxi kernel & Adobe Creative Cloud
Lähteülesandeks on analüüsida üht tarkvara arendus- ja üht ärimudelit mõne konkreetse projekti näitel. Info külluse ja dokumentatsiooni rohkuse kaalutlustel valisin analüüsiks Linuxi (kerneli) arenduse. Kuivõrd arendus algas 1991 aastal ning kestab tänaseni, toon välja mõned olulisemad punktid arendusajaloost, et arendusmudelit kirjeldada.
3. Juulil 1991 postitas L. Torvalds hilja õhtul, võib isegi öelda öösel (00:50 GMT) minixi uudistegruppi (comp.os.minix) pöördumise, milles andis teada, et töötab projekti kallal ning tal läheks tarvis posixi standardeid masin-loetaval kujul.
From: torvalds@klaava.Helsinki.FI (Linus
Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Gcc-1.40 and a posix-question
Message-ID:
Date: 3 Jul 91 10:00:50 GMT
Hello netlanders,
Due to a project I'm working on (in minix), I'm interested in the posix
standard definition. Could somebody please point me to a (preferably)
machine-readable format of the latest posix rules? Ftp-sites would be
nice.
(Allikas: Carnegie Mellon ülikooli veebileht [1])
Posixi standardi definitsiooni puhul on tegu IEEE standardite kogumiga ning tehniliselt failisüsteemiga, mis tagab, et ühe Unixi baasil töötavas süsteemis arendatud rakendused toimiksid ka teiste Unixi baasil töötavates süsteemides. (2)
Vähem kui kaks kuud hiljem postitas L. Torvalds praeguseks legendaarse postituse, kus andis teada edusammudest bashi ja gcc portimisel ning küsis edasise arenduse osas minixi kasutajatelt tagasisidet minixi tugevuste ja nõrkuste kohta.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID:
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(Allikas: Carnegie Mellon ülikooli veebileht)
Siin võib tõmmata paralleeli erinevate inkrementaalsete ja iteratiivsete mudelitega, kus toimub algfaasis planeerimine. Kõigepealt suheldes kliendiga pannakse paika kontseptsioon ja nõuded, kuid võib ka täheldada, et osalt tegeleb Torvalds ka juba arhitektuuri disainiga.
Pärast
mitmeid uudistegruppidesse postitamisi tegi L. Torvalds oma senise töö
kättesaadavaks aadressil https://nic.funet.fi/, mis tegutseb tänaseni, jagades mõningast vabavaralist
tarkvara. Seega oli senise tegevuse näol täidetud nüüdseks välja kujunenud vaba
tarkvara arendusmudeli kaks projekti alustamise viisi nagu on välja toodud
ITSPEA lehel ja itkolledži wiki lehel (3):
1. Algataja teatab
avalikult plaanist alustada projekti (foorumi, listi vms kaudu).
2. Algataja avaldab senise eraviisilise töö tulemuse vaba tarkvara projektiga (näiteks avab Githubi projekti)
L. Torvaldsi kirjutatud ajaloost võib lugeda, et ta sai e-kirjasid inimestelt, kes tahtsid saada beta-testijateks. Ligikaudu 91. aasta detsembriks jõuti versioonini 0.11. Ei ole teada, kui paljud koodi kirjutamisega panustasid. Ei ole ka teada, kas erinevate „töölõikude“ kallal töötati paralleelselt või mitte, kuid uudistegruppi tehtud postitustest käib läbi Phil Nelsoni nimi ning Torvalds otsis inimesi, kellel on olnud kokkupuude minixi teekide arendamisega. Eesmärk oli copyright või avaliku domeeni litsentsi raames varasemalt kirjutatud koodi kasutamine. Ühtlasi on loetav, et Torvaldsi nn roadmap oli huvilistele nic.funet.fi lehel ’’.plan’’ failina kättesaadav.
Linuxi kerneli arendamisel tasub eraldi ära markida kuidas viidi läbi vigade otsimine e ͉debuggin͉g. Ei eksisteerinud veel versioonihaldusega koodivaramuid nagu Git, CVS vms, samuti vea- ja ülesandehaldusvahendeid. Kui kuskil kernelis oli viga, tuli see tuvastada ning versioonihaldus toimus tõenöoliselt paberi ja pastakaga. Probleemiks oli asjaolu, et kriitise vea olemasolul tegi arvuti (386) restart-i, veateadet ei saanud, RAM kustus. Torvalds kasutas algselt vigade otsimiseks assembleri käsku „die: jmp die“. Seda koodi strateegilistesse kohtadesse sisestades sai ta teada, et arvuti taaskäivitamisel asus viga enne „jmp die“ käsklust. Alates versioonist 0.12 hakkas kernel sisaldama mitte-kriitilisi osasid, mis olid arendatud kogukonna poolt.
Algselt toimus Linuxi kerneli arendamine suuremal või vähemal määral seega ühe isiku poolt, hiljem, alates versioonist 0.12, juba laiema hulga inimeste poolt ning kõik toetus Torvaldsi nägemusele, .plan failile ning kogukonna tagasisidele. Seda võiks nimetada ka kauboiarenduseks, millel ei ole küll ametlikku definitsiooni, kuid mille all mõeldakse sellist arenduskeskkonda, kus programmeerijatel on suur autonoomsus; programmeerija paneb paika arenduskava, programmeerimiskeele, algoritmid, arendustööriistad, arendusraamistiku, koodi kirjutamise stiili. Sellise metoodika või täpsemalt metoodika puudumise puhul on välja toodud neli suurt puudujääki:
- Toote väljalaskegraafik on puudulik: toodet arendatakse hobina, seega ei ole kindlat arengukava või konkreetseid kuupäevasid.
- Kogenematud arendajad: kauboiarendajad on tarkvarahuvilised
(hobbyists) ja tudengid, kes ei ole
elukutselised arendajad. Üksi või väikses grupis töötades ei peeta kinni
metoodikast, mida kasutatakse suurte süsteemide arendamisel nagu selge süsteemi
build, hoolikas testimine ja
versiooni manageerimine.
- Määratlemata disaini-nõuded: arendus toimub
„kauboi“ enda eesmärgi huvides, ei pöörata rõhku disainile ja süsteemi kasvades
tekivad disaini puudujääkidest tingitud probleemid.
- Mittetäielikkus: kui kauboiarendaja enda eesmärgid on täidetud, jääb projekt unarusse ja arendaja kaotab motivatsiooni, et arendust jätkata.
(Hatta, 2021)
Kõik need punktid on õiged, kuid võiks öelda sellise arendusmeetodi puhul isegi paratamatud. Eric S. Raymondi töös „Katedraal ja turg“ on näitena välja toodud, et Linus Torvalds tegi algse kerneli arendamisel pea aegu iganädalasi väljalaskeid. Eric S. Raymond on Linuxi arendusmetoodika kokku võtnud iseloomustavate punktidena:
- Head programmeerijad teavad mida kirjutada. Suurepärased programmeerijad teavad mida üle kirjutada ja mida taaskasutada.
- Oma kasutajate kaas-arendajatena kohtlemine on kõige vähem-tülikaim tee kiire järgulise koodi paranduseni ja efektiivse veaparanduseni.
- Avalikusta varakult, tihti ja kuula oma kliente.
- Suure hulga beta-testijate ja kaas-arendajate hulga juures leitakse iga probleem kiiresti üles ja lahendus on kellelegi teada.
Kolmas punkt sellest strateegiast on omane agiilsetele mudelitele ning iteratiivsetele mudelitele nagu spiraalmudel, kus töötatakse välja prototüüp, mida järk-järgult parandatakse ning funktsionaalsusi lisatakse. „Katedraal ja turg“ tekstis ei õnnestunud mul leida viidet sellele, mida E. S. Raymond ütles helisalvestisel, et L. Torvalds avalikustas koodi vähemalt kord päevas. (Helisalvestised: [1]) Kui see tõele vastab, on see on võrreldav agiilsete mudelite sprintide kestustega. Helisalvestiselt on muidugi ka kuulda, et kiire avalikustamise taga oli koodi panustajate kiire gratifitseerimine. Panustajad ei pidanud ootama pool aastat, et näha oma panust integreerituna tootes. Keeleliselt on muidugi „kogenematud arendajad“ (ingl. keeles inexperienced developers) äärmiselt eksitav, sest on vähe tarkvarahuvilisi ja ka tudengeid, kes suudaksid nullist uue kerneli programmeerida. Mis puutub testimisse ja versiooni manageerimisse, siis oli manageerimine algselt täielikult Torvaldsi kätes. Kasutajad ja beta-testijad said saata oma koodi ja paranduste ettepanekud, kuid uue versiooni „kokku panek“ sõltus lõplikult ikkagi Torvaldsist. Siit tuleneb ka Raymondi järeldus, et turu kontseptsiooni põhjal on kerge toodet arendada, kuid ei ole kerge tootearendusega alustada. Nagu eelnevast teame, siis enne kerneli versiooni 0.12 oli töö suuresti L. Torvaldsi enda poolt tehtud.
Selle versiooni avalikustamismärkmetes oli ka plaan liikuda edasi GNU GPL litsentsiga. Ainuüksi kernelist töötava süsteemi saamiseks ei piisanud, ning töötava OS-i saamiseks kasutati seni GNU tarkvara (käsuprotsessor, kompileerija, teegid jne). (vt avaldusmärkmeid versioon 0.01 kohta). Uue litsentsi alla jõuti alles kerneli versiooni 0.99 avalikustamisega 92. aastal, ning siis hakkasid arenduses toimuma hüppelised muudatused, mis olid seotud ka erinevate ärimudelitega. 1993. aastal loodud „Debian Project“ oli üks kogukonna projektidest, mis toimetas GNU ja Linuxi enda vaimus. (4) Kommertsiaalse poole esindajatena on kõige paremini tuntud Red Hat - IBM’i tütarettevõte - ja SUSE. Mainitud ettevõtted keskenduvad eelkõige erinevatele serverilahendustele. (5, 6) Kõrvalmärkusena võib viidatud kodulehtesid külastades tähele panna, et Red Hat on tänaseks rohkem keskendunud erinevatele pilveteenustele.
Edasised arengud tarkvaraarenduses, pärast aastat 2000, puudutavad juba erinevate organisatsioonide loomist nagu Open Source Development Lab ja Linux Foundation, mis on rohkem seotud ärimudelitega, kui arendusmetoodikaga. Küll aga võib Linuxi kerneli tarkvaraarendusmudeli lühianalüüsi kokkuvõtteks üldistavalt lisada, et algse vaba tarkvara arendusmudeli üheks tunnuseks on teiste vabavaraliste projektidega koostöö tegemine (nt GUI GNOME kasutusele võtmine) ja lahenduste integreerimine.
Kui enamus vaba tarkvara ärimudelitest põhinevad tervikliku tugisüsteemi pakkumisel nagu eelmainitud Red Hat ja Suse või kombineerivad pilveteenust alla laetava tarkvarakomponendiga, siis Adobe Creative Cloud (ACC) on üks hübriidsetest lahendustest, mis kasutab ühel ajal nii SaaS mudelit kui ka traditsioonilist omandvara mudelit.
ACC sisaldab erinevaid programme ja teenuseid nagu Photoshop, Illustrator, Acrobat DC, Premiere Pro, InDesign ja Creative Clous Express. ACC mudel ühendab erinevaid variante nagu kuutasuline (Creative Cloud Photography 9.99$ kuus, Creative Cloud All Apps 52.99$ kuus), prooviperiood (7 päeva üksikisikule, tudengile, õpetajale ja 14 päeva meeskonnale või ettevõttele). Võimalus on ka tellida üksikprogramme, nt Photoshop, eraldi tellimusena (indiviidile 20.99$ kuus).
ACC distributsioonimudel on hübriidne, ühendades SaaS lahenduse nö traditsioonilise tarkvara allalaadimise mudeliga, mis on samuti hübriidseks muudetud. Klient tõmbab alla Creative Cloud Desktop rakenduse, mille kaudu pääseb ligi programmidele. Uuendused, teegid ja mallid tulevad läbi pilve, klient ei pea ostma eraldi uut litsentsi. Tõenäoliselt ei ole aga abonendi tühistamise korral enam „desktop“ rakendusega palju teha, sest klassikalist omandvara arvutisse ei tõmmata. Selle punkti juures võib aga see julgelt vastu vaielda, kes ACC-d varem kasutanud on. Muul määral ei erine ACC oma loomult teistest lahendustest: lähtekood on suletud, käibeallikas on abonendipõhine. (5)
Täpsema kirjelduse saamiseks võib vaadata skeemi, ehkki ACC sihtgrupp ei ole hübriidmudelina kindlasti ainult B2B, vaid ka B2C.
(Allikas: www.altexoft.com)
Kasutatud
kirjandus:
- Hatta, Masayuki. Cowboys and the Eternal September: Transfiguration of Hacker Aesthetics. Annals of Business Administrative Science. 2021. Loetav: https://www.jstage.jst.go.jp/article/abas/advpub/0/advpub_0210923a/_pdf
- Raymond, Eric Steven. The Cathedral and The Bazaar. O’Reilly 1999. Loetav: http://www.catb.org/~esr/writings/cathedral-bazaar/
Internetiallikad:
- Carnegie Mellon ülikooli veebileht https://www.cs.cmu.edu/~awb/linux.history.html
- https://en.wikipedia.org/wiki/POSIX
- https://wiki.itcollege.ee/index.php/E-ITSPEA_11:_Arendus-_ja_%C3%A4rimudelid
- https://www.debian.org/doc/manuals/project-history/intro.en.html
- https://www.suse.com/products/
- https://www.redhat.com/en
- https://www.adobe.com/creativecloud.html
- Altexoft. Software Business Models, Examples, Revenue Streams, and Characteristics for Products, Services, and Platforms. https://www.altexsoft.com/blog/business/software-business-models-examples-revenue-streams-and-characteristics-for-products-services-and-platforms/
Helisalvestised:
Comments
Post a Comment